Security and Rate Limits

Security Hardening and Rate Limiting

An Express 24,430 app that works is not an Express app that is safe to publish. The server you wrote in First Server announces itself with X-Powered-By: Express, accepts a JSON body of any size, answers the same request ten thousand times a second, and trusts every field a client puts in a POST body. None of that shows up in a test suite; it shows up in a bill.

Hardening is not one library but a short list of checkable decisions, most of them made by putting the right middleware in the right order. A rate limiter mounted after the body parser has already paid to parse the attacker's payload; a CSRF check mounted before the session middleware has no session to bind its token to. The pipeline below is the order this section builds.

Where each defense sits in the request path, and the section that covers it
Where each defense sits in the request path, and the section that covers it

Two topics stay outside it. Content Security Policy and the browser side of security headers are Front-End Web Development material: you will see which headers Helmet 10,736 emits and how to tune them for an API, not what each directive means. Dependency auditing, install scripts, typosquatting and Node's permission model are Security and the Supply Chain. Everything printed below came from a real Express 5.2.1 server on Node.js 25.8.0 2,131 with helmet 8.3.0, cors 2.8.6 6,195 , csrf-csrf 4.0.3 196 , express-rate-limit 8.7.0 3,306 and zod 4.6.5.

Subsections