HOW SECURE IS CONVEX? (A-)

Rating: A-

Convex scores high on defaults: functions execute server-side, auth checks are explicit, and there’s no anon-key-style shortcut to the database. The score drops only because client-side state can still leak sensitive fields if selectors are wrong.

Top failure modes

1. Overfetching in queries — Returning whole documents instead of projected fields leaks internal state (stripe_customer_id, internal flags).

2. Missing auth checks in mutations — Convex mutations are server-side but auth identity has to be asserted explicitly; skipping this gives anonymous callers full write access.

3. Public functions with sensitive side effects — Marking a function ‘public’ when it should require a user session.

How to make Convex safer

1. Treat the defaults as a starting point, not a secure configuration.
2. Audit each failure mode above against your specific deployment.
3. Run an automated scan against the deployed app — UI signals rarely surface the backend issues.
4. Re-scan after every material change (new table, new Edge Function, new env var).

For the full analysis of Convex’s platform, defaults, and the failure modes we find on real deployments, see Is Convex Safe?.

Related

• Firebase vs Convex Security

FAQ

Is Convex more secure than Firebase?

On defaults, yes — Convex has no equivalent to Firebase’s anon client SDK with open rules. Functions run on the server, and client code can only invoke explicitly published queries and mutations.

Does Convex have Row Level Security?

Not as a declarative feature. You enforce authorization in the query/mutation body: check ctx.auth.getUserIdentity() and branch on it. This is safer when remembered and worse when skipped.

Can I leak data through Convex?

Yes — the most common vector is overfetching. Return only the fields the UI needs, and never ship internal-only fields (audit markers, revenue data, encryption keys) through a public query.