Not a 200-item compliance checklist. The dozen things that catch most of the real issues in early-stage products.

Auth boundaries

Every endpoint should have an explicit answer to “who can call this?” — not by convention, but in code. If an unauthenticated user can hit an endpoint, that should be visible in the endpoint’s declaration, not buried in middleware three files away.

Common failure: an admin API that’s protected by “only linked from the admin UI.” That’s not protection. If you can curl it, so can someone else.

Secrets in the right places

Environment variables at rest, not in the repo. Not in .env.example with real values that got committed once by accident and are still in the git history. Rotate anything that touched a public repo, even for five minutes.

If you have a secrets manager (Vault, Doppler, cloud provider equivalent), use it. If you don’t, a .env on the server that’s readable only by the app user beats nothing.

Dependency hygiene

npm audit, pip-audit, or your ecosystem’s equivalent, run in CI. Failing the build on known-vulnerable dependencies isn’t overkill — it’s the minimum bar.

Pin your dependencies. Not because the maintainers are hostile, but because a transitive 4.2.x becoming a 4.3.x shouldn’t be able to change what your app does without you noticing.

Logging you’ll want later

Log the outcome of every auth attempt. Log which user did which write action, and when. Not the full request bodies (that leaks PII) — just enough to reconstruct “who did what.”

You will not care about these logs until the day you need them. That’s when you’ll wish you’d added them six months ago.

Rate limits on anything that costs

Login endpoints. Password reset. API endpoints that call paid services (email, SMS, LLM APIs). Anything an attacker could weaponize against your credit card. A simple per-IP token bucket is enough for most cases; you can always add more later.

The rest of the list, briefly

  • HTTPS on everything, even internal endpoints.
  • CSRF protection on any state-changing endpoint that uses cookies for auth.
  • Content Security Policy header, even a permissive one — you can tighten it later.
  • Regular backups, and one test restore. Untested backups don’t exist.
  • A written incident response plan, even a one-page one. When it’s 3am, you don’t want to be figuring out who to call.