API Security Checklist: 10 Things We Verify Before Every Production Launch

Cover design: Vishvajeet Shukla

Every API we ship — whether it's a client's or one of our own products — goes through the same pass before it's allowed near production traffic. None of this is exotic. Almost every real incident we've seen traces back to one of these ten being skipped under deadline pressure, not to some novel attack.

1. Authentication is never optional, even internally

"It's an internal service" is how half of these gaps get introduced. Every route gets an explicit auth check — no route is assumed safe because of where it's deployed.

2. Authorization is checked per-resource, not just per-route

A valid, logged-in user hitting /orders/482 still needs to be checked against owning order 482. Route-level auth without object-level authorization is the single most common gap we find in review — it's an easy pass on a login screen and a quiet data leak everywhere else.

3. Rate limiting on every public-facing route

Not just the login endpoint. Search, export, and "resend OTP" endpoints get hit by scrapers and credential-stuffing tools just as often, and they're usually the ones someone forgot to throttle.

4. Input validation at the boundary, not deep in business logic

Validate shape, type, and length the moment a request enters the system — before it reaches a database query or gets forwarded to another service. Validating "eventually, somewhere downstream" means every code path between the boundary and that check is a potential hole.

5. Parameterized queries, always

String-concatenated SQL still shows up in review, usually in a "quick admin script" that was never meant to touch production and then did anyway.

6. Secrets never live in the repo

Environment variables, a secrets manager, or a vault — never a committed .env, never a hardcoded key "just for now." A key that's ever touched git history has to be rotated, not just deleted.

7. CORS is an allowlist, not a wildcard

Access-Control-Allow-Origin: * on anything that reads authenticated data is a standing invitation. Every API gets an explicit origin allowlist.

8. Errors don't leak stack traces to the client

A stack trace in a production error response hands an attacker your framework version, file paths, and sometimes a query string. Log the detail server-side; return a generic message to the client.

9. File uploads are validated by content, not by extension

Renaming a script to .jpg defeats an extension check trivially. We validate actual file signatures/MIME type and cap size before anything touches storage.

10. Dependencies get an audit pass before launch, not just at project start

A clean npm audit on day one doesn't mean much six months later. This is the last checklist item precisely because it's the easiest one to forget once a project is "done."

None of these ten are hard. The failure mode is always the same — one of them gets skipped once, under a deadline, and it's the one that mattered.

If you're evaluating a vendor or an internal team's API work, ask to see this list applied to a real endpoint, not just described in the abstract. The gap between "we know API security" and "we can show you exactly where we checked it" is usually where the real risk lives.