Most Node.js APIs are not secured. They have a few security packages installed, which is not the same thing. The packages sit in the dependency tree, the developer feels covered, and the actual holes stay open because nobody walked through them deliberately.
Security is not a library you install. It is a set of decisions you make on purpose. This is the checklist we run before any Node.js API goes to production, ordered roughly by how likely each gap is to actually hurt you rather than by how often it appears in tutorials.
Start With the Threat Model, Not the Middleware
Before a single package goes in, answer one question: what would an attacker want from this API, and what is the cheapest way for them to get it?
For most business APIs the answer is data. Customer records, credentials, payment tokens, internal information that has resale or leverage value. The cheapest routes to that data are almost always the same handful: a broken authentication check, an endpoint that trusts input it should not, or a secret sitting somewhere it should not be.
Knowing this shapes everything else. You are not trying to be secure against everything. You are trying to close the specific doors an attacker will actually try, in the order they will try them.
Authentication: Verify Identity on Every Request
The most common serious failure is not weak passwords. It is endpoints that assume the request is authenticated because another endpoint was.
Every protected route must verify identity independently. A valid token on the login route means nothing on the account route unless the account route checks it too. This sounds obvious and is violated constantly, usually because auth is applied at the wrong layer or a new route is added without the middleware that guards its neighbours.
Use a well-tested token mechanism rather than rolling your own. Set sensible expiry. Validate the signature, the expiry, and the issuer on every request. Store nothing sensitive in the token payload, because tokens are readable even when they are signed. And make sure logout and token revocation actually work, because a token that cannot be revoked is a permanent key.
Authorisation: Authentication Is Not Enough
Authentication answers "who are you". Authorisation answers "are you allowed to do this". Confusing the two is how one customer ends up able to read another customer's data.
The classic failure is the object reference. A request comes in for resource ID 4012, the API confirms the caller is logged in, and returns the resource without checking whether this particular user owns it. Change the ID to 4013 and you have someone else's data. This is one of the most common real-world API breaches, and it is invisible in testing because your test account only ever requests its own IDs.
Every data access must check ownership or role, not just valid login. Treat every ID in a request as attacker-controlled, because it is. We covered the broader question of building APIs that survive real conditions in how to build a GraphQL API that performs in production, and the same ownership discipline applies to REST.
Input Validation: Trust Nothing From the Client
Every value that arrives from a client is hostile until proven otherwise. Not because every caller is malicious, but because you cannot tell which one is.
Validate the shape, type, and bounds of every input at the boundary, before it touches your logic or your database. Use a schema validator so the rules are explicit and consistent rather than scattered through the code as ad hoc checks. Reject anything that does not match rather than trying to clean it, because cleaning attacker input is a game you lose.
Pay special attention to anything that becomes a database query, a file path, a shell command, or HTML sent back to a browser. These are where unvalidated input turns into injection, and injection is where a small oversight becomes a full compromise. Parameterised queries are not optional, they are the baseline.
Rate Limiting: Slow the Attacker Down
An API with no rate limiting is an open invitation to brute force. Login endpoints get password-guessed, expensive endpoints get hammered until the service falls over, and scraping runs unchecked.
Rate limit by IP and, where you can, by authenticated user. Apply stricter limits to sensitive endpoints like login, password reset, and anything that sends email or costs money to run. Return the right status code so legitimate clients back off correctly. This is a small amount of work that removes an entire class of cheap attacks, which is why it belongs near the top of the list rather than the bottom. We touched on load behaviour in what makes a REST API hold up under load, and rate limiting is as much a stability control as a security one.
Secrets: Get Them Out of the Code
Hardcoded secrets are still one of the most common ways APIs get compromised, usually through a leaked repository or a misconfigured deployment.
No secret belongs in source control. Not database credentials, not API keys, not signing secrets. Use environment variables or a secrets manager, keep them out of the repository entirely, and rotate anything that has ever been committed even once, because git remembers forever. Make sure secrets are not logged, not returned in error messages, and not exposed through a debug endpoint that someone forgot to remove.
This is unglamorous and it prevents a genuinely disproportionate share of real breaches.
Transport and Headers: Close the Easy Gaps
Serve the API only over HTTPS, with no plaintext fallback. Set the security headers that stop a browser from doing dangerous things on your behalf, including strict transport security and sensible content type handling. Configure cross-origin resource sharing deliberately rather than allowing every origin because it made a bug go away during development. A wildcard CORS policy on an authenticated API is a quiet, serious hole.
These are close to free once you know to set them, and they close a range of opportunistic attacks.
Error Handling: Do Not Teach the Attacker
Verbose errors are a gift to anyone probing your API. A stack trace tells them your framework, your file structure, and often your database. A detailed authentication error tells them whether the username was real.
Return generic errors to clients and keep the detail in your internal logs. Never leak stack traces, database messages, or internal paths in a response. Make authentication failures indistinguishable so an attacker cannot tell whether they got the identity wrong or the credential wrong.
Dependencies: Your Code Is Not the Whole Attack Surface
A Node.js API is mostly other people's code. Every dependency is part of your attack surface, and a vulnerability in a package you never think about is still a vulnerability in your API.
Audit dependencies regularly, keep them updated, and remove anything you are not actually using. Be cautious about pulling in a large package for a small job, because each one is a door you now have to trust someone else to keep locked.
Logging and Monitoring: Know When It Happens
The final gap is not a hole an attacker walks through, it is your inability to notice when one does. An API that is being attacked and has no logging is being attacked silently.
Log authentication events, authorisation failures, and unusual patterns. Monitor for spikes that look like probing or brute force. You cannot respond to what you cannot see, and the difference between a contained incident and a disaster is usually how quickly someone noticed.
The Checklist Is Only Useful If You Run It
None of these items is exotic. That is the point. Real breaches rarely come from a clever novel exploit. They come from a known door left open because nobody deliberately checked it.
The value here is not the individual controls, it is the habit of walking the list before launch every single time, rather than trusting that the packages in the dependency tree added up to security on their own. We treat this as a gate, not a nice-to-have, which is why the APIs we ship are fast without being fragile.
Build the API to be secure from the first commit and this checklist is a confirmation. Bolt security on the week before launch and it becomes a scramble that always misses something.