The app security checklist every founder needs before launch

Most security problems are not discovered before launch. They are discovered after, by users, researchers, or attackers, at a time when fixing them is expensive and embarrassing. This checklist covers the minimum a founder should verify before putting real users on a new app.

Authentication and session management

• Passwords are hashed with bcrypt, Argon2, or equivalent. Never MD5, SHA1, or SHA256 alone.
• Sessions expire. Inactive sessions are invalidated after a reasonable timeout.
• JWT tokens have short expiry and are validated on every request, not just at login.
• Password reset flows use short-lived tokens sent to verified email addresses.
• Account enumeration is not possible through login or password reset error messages.

Authorization

• Every data operation checks that the requesting user owns or has permission to access the resource.
• Role-based access controls are enforced server-side, not just in the UI.
• Admin routes require explicit admin role checks, not just authentication.
• Database queries use parameterized inputs. No raw string interpolation.

API and network

• Rate limiting is applied to authentication endpoints, signup, and any endpoint that triggers external actions.
• API keys and secrets are in environment variables, not in source code or client bundles.
• CORS is configured to allow only your known origins. Wildcard (*) is not acceptable in production.
• HTTPS is enforced. HTTP requests redirect to HTTPS.
• Sensitive operations require re-authentication or secondary confirmation.

Data handling

• Personally identifiable information (PII) is stored only where necessary.
• Sensitive fields (SSNs, payment data, health records) are encrypted at rest.
• Database backups exist and are tested.
• Row-level security (if using Supabase or similar) is explicitly defined and tested.
• You have a documented answer for "where is user data stored and who can access it."

Dependency and infrastructure

• npm audit or equivalent shows no high or critical vulnerabilities in direct dependencies.
• Third-party services (analytics, error tracking, payments) operate with the minimum permissions they need.
• No keys, tokens, or credentials appear in version control history. Run git log and check.
• Error messages shown to users do not include stack traces or internal system details.

What to do with this list

Work through it before you send your first invite link. The items that take the longest to fix are the ones that tend to already be checked: authentication and HTTPS. The items that are usually missing are authorization, rate limiting, and secrets in bundles.

If you want a second set of eyes on any of these, a security audit walks through each layer with access to the actual code and infrastructure, not just a checklist.