Overview

Security in the starter is layered and enforced server-side in Convex. Hiding a button is convenience only — every guarantee lives in a backend function that re-checks the caller. This section covers what protects an account after login. For login-time protections (passwords, OAuth, magic links, 2FA) see Authentication.

The pieces

• Sensitive Action Protection — step-up verification before dangerous actions (deleting an org, removing a member, cancelling a subscription). Works for every account type, including OAuth and magic-link users that login-time 2FA never challenges.
• Verification methods — the three ways a user can clear a step-up: Fresh Session, Password Confirmation, and Email Verification Codes.
• Rate Limiting — Convex-component limits on the abuse-prone surfaces (verification emails, password attempts, uploads).
• Audit Log — a first-party record of security-relevant events, written in the same transaction as the change.
• Super-Admin Access — a server-side, env-gated platform admin boundary, separate from per-workspace roles.

Principles

• Server-side is the boundary. A valid session token can call an endpoint directly, so authorization is always re-checked in the function.
• Fail closed. Unknown providers, missing config, and unverified emails default to "denied," not "allowed."
• Secrets are never stored in the clear. Verification codes and session scopes are stored only as salted, peppered SHA-256 hashes.
• Auditable denials. Denied admin writes return a structured failure (rather than throwing) so the denial is recorded instead of rolled back.

Before you launch

Walk the Security Checklist before exposing the app to real users.