JakubSECURITY / RESEARCH
← All write-ups

A pre-launch web application security checklist

The checks worth running before a web app or API goes live — access control, authentication, input handling, APIs, configuration and dependencies.

This is the shortlist I run through before a web application or API ships. It does not replace a real assessment, but it catches the issues that most often turn into incidents — and it is a good way to see how much of your attack surface you can reason about.

Access control

  • Every object reference is authorized on the server, not just hidden in the UI.
  • Identifiers cannot be swapped to reach another user's data (IDOR / BOLA).
  • Privileged and admin actions re-check the caller's role server-side, on every call.
  • The default for a new endpoint is deny, not allow.

Authentication & sessions

  • Password reset and email-change flows bind their token to the account and expire it after use.
  • Sessions are invalidated on logout, password change and role change.
  • Multi-factor, where offered, cannot be skipped by manipulating the flow.
  • Rate limiting and lockout protect login, reset and one-time-code endpoints.

Input handling

  • Output is contextually encoded to prevent stored and reflected XSS.
  • Database access uses parameterized queries, never string-built SQL.
  • File uploads validate type and size, and are stored off the web root.
  • Server-side requests validate the destination to prevent SSRF.

APIs

  • Responses expose only the fields the interface needs — no over-fetching by default.
  • Object- and function-level authorization is checked on every API route.
  • Rate limits and quotas exist on expensive and abusable operations.
  • GraphQL depth/complexity is bounded and introspection is intentional, not accidental.

Configuration & secrets

  • Security headers are set: CSP, HSTS, X-Content-Type-Options, a sensible referrer policy.
  • No secrets in source control, client bundles or error pages.
  • Verbose errors and debug endpoints are off in production.
  • CORS is an allowlist, not a wildcard on credentialed endpoints.

Dependencies & monitoring

  • Dependencies are inventoried and scanned for known vulnerabilities.
  • There is a way to ship a security patch quickly.
  • Authentication and access-control failures are logged and alertable.
  • There is a published, monitored path for people to report security issues.

If any line here is hard to answer with confidence, that is usually the most valuable place to start a proper test.