AnestedAnested
Blog
Engineering·7 min read

Node.js API Security: The Checklist We Ship With

Every Express API we ship passes the same security review. Here is the actual checklist — from rate limiting and JWT handling to the SQL injection mistakes we still see in code reviews.

By Anested Engineering

Every Express API that leaves our workshop passes the same security review before it touches production. The checklist is short enough to actually follow, which is the point — a forty-item security document that nobody reads protects nothing.

First, authentication boundaries. Tokens are verified on every protected route through middleware, never inside individual handlers where a refactor can silently drop the check. JWTs get short expiries, and anything privileged re-reads the user's role from the database rather than trusting claims baked into a token that might be a day old.

Second, rate limiting on every public surface — and different limits for different surfaces. Login endpoints get a handful of attempts per window, because credential stuffing is a volume business. Public form endpoints get enough headroom for real users and no more. The limiter is boring middleware, and boring is what you want standing in front of a brute-force attack.

Third, parameterized queries with no exceptions. Every SQL statement in our codebase uses placeholders; string interpolation into a query is an automatic review rejection, even when the value 'cannot possibly' come from a user. Values that genuinely must alter query structure — a sort column, an interval — come from a hardcoded whitelist, never from the request.

Fourth, validate at the boundary and escape at the exit. Request bodies are checked for shape and sanity the moment they arrive. Anything that later goes into an email, a log line, or an HTML template gets escaped for that destination. Cross-site scripting is almost always an output problem wearing an input costume.

Finally, the quiet essentials: security headers via Helmet, CORS locked to known origins, secrets in environment variables that never reach the repository, and error responses that say 'something went wrong' to the client while the real stack trace goes to logs. Attackers read error messages more carefully than most developers do.

None of this is exotic. That is the lesson we would offer any team: the APIs that get breached are rarely missing advanced defenses — they are missing the basics, applied consistently. A checklist you actually run beats an architecture diagram you admire.

Need help with something we wrote about?

Our engineers answer support queries directly — hosting, databases, code, or anything from this post.