Express.js Security Guide: Helmet, Sessions, Rate Limiting and Safe Middleware

Express gives you a router and a middleware chain, and almost nothing else, so every security property of an Express application is something a team chose to add, configure and keep in order. The defaults are deliberately minimal: no security headers, a session cookie that is not marked Secure, no rate limiting, a fingerprinting header and an in-memory session store that the maintainers say is not for production. This guide turns the official Express production security guidance, the Helmet and express-session documentation and the OWASP Node.js cheat sheet into a hardening baseline for Express 4 and 5. It is written for Node.js developers, application security engineers and reviewers who own or assess Express services, and it goes deeper on Express specifics than the general Node.js Security Guide.

Key takeaways

• Middleware order is the security model. Helmet, body limits, rate limiting, session and authentication must run before the routes they protect, and the error handler must be last.
• express-session defaults need changing. The cookie is HttpOnly but not Secure, SameSite is off, the name is the fingerprintable connect.sid and MemoryStore is not designed for production.
• trust proxy decides who your users are. req.ip, req.protocol and req.hostname come from X-Forwarded-* headers once it is enabled, so a wrong value breaks rate limiting, Secure cookies and audit logs.
• Helmet is a baseline, not a policy. It sets 13 headers with sensible defaults, but the Content Security Policy still has to be written for your application and tested in report-only mode first.
• Stay on a patched major version. Express 3.x has had no fixes since 2015, and recent 4.x releases fixed open redirect and XSS flaws in res.redirect and res.location, so version currency is a control in itself.

How identity and access work in Express

Express has no built-in user model. Identity arrives through middleware you add: a session layer, an authentication strategy library or a token verifier, followed by your own authorisation checks. That makes the request pipeline the place where identity can be lost, spoofed or skipped.

Sessions: express-session versus cookie-session

The Express best practices page describes two session modules. express-session stores session data on the server and puts only a signed session ID in the cookie. cookie-session serialises the whole session into the cookie, which the Express team says suits only small sessions of primitive values, kept under 4093 bytes per domain, and only where the client may see the data.

Call req.session.regenerate() after successful login so the pre-authentication session ID is discarded, which is the documented defence against fixation (see the Session Fixation Guide). At logout, clear the user, save and regenerate, or call req.session.destroy(), and make sure the server-side record is removed, not just the cookie.

Authentication and authorisation middleware

• Mount order: authentication middleware must be mounted before the routers it protects. A router mounted above app.use(requireAuth) is public, and this is the most common Express access control bug found in code review.
• Deny by default: apply an authentication guard at the router level and explicitly mark the few public routes, rather than adding a guard to each private route and hoping none is missed.
• Object-level checks: a valid session says who the caller is, not what they may touch. Check ownership or tenancy for every :id parameter in the handler or a shared policy function.
• Token APIs: for bearer tokens, verify signature, issuer, audience and expiry in middleware and pin the accepted algorithms. See the JWT Security Guide.
• Express 5 async handling: rejected promises from async handlers now go to the error handler. In Express 4 an unawaited rejection inside an auth check can leave a request hanging or skip the check, so wrap async middleware or upgrade.

Admin roles and privileged access

Express apps usually grow an admin surface: an /admin router, a health or metrics endpoint, a debug route someone added during an incident. These are privileged functions and deserve stronger controls than the rest of the app.

• Separate the router: mount admin routes on their own router with a role check applied once at the top, and consider serving them on a separate hostname or internal-only listener so the same-origin policy and network controls also apply (ASVS 5.0 V3.5.4).
• Step-up authentication: require a recent strong authentication for destructive admin actions, and record the session's authentication time to enforce it.
• Use state-changing methods correctly: sensitive actions on POST, PUT, PATCH or DELETE only (ASVS 5.0 V3.5.3), with CSRF protection for cookie-authenticated forms. The OWASP Node.js cheat sheet notes that csurf is deprecated; see the CSRF Prevention Guide for current patterns.
• No debug in production: remove or gate debug and documentation routes (ASVS 5.0 V13.4.2, V13.4.5), and set NODE_ENV=production so Express and template engines stop returning verbose errors.
• Static files: Express 5 ignores dotfiles and hidden directories in express.static() and res.sendFile() by default. On Express 4, set dotfiles: 'ignore' or 'deny' and never serve the project root, which exposes .git and .env (ASVS 5.0 V13.4.1).

Integrations, API tokens and service accounts

Most Express services hold machine credentials: database passwords, cloud keys, payment and email API keys, the session signing secret and outbound OAuth client secrets. These non-human identities are often more powerful than any user session.

• Secrets out of code: load the session secret and API keys from a secrets manager or injected environment at start-up, never from a committed .env. Rotate with the array form of secret so users stay logged in. See the Secrets Management Guide.
• Least privilege per integration: give each downstream key the narrowest scope the service needs, and separate read and write credentials where the provider allows. See the API Key Management Guide.
• Inbound service tokens: for service-to-service calls into the app, prefer mTLS or short-lived signed tokens over static shared keys, and verify them in dedicated middleware (ASVS 5.0 V13.2.1).
• Outbound allowlists: if a route fetches a URL supplied by a user or a webhook, restrict destinations to an allowlist (ASVS 5.0 V13.2.4, V13.2.5) to prevent the app's network identity being used for SSRF.
• Dependencies are integrations too: an Express app typically pulls hundreds of transitive packages that run with the same access to those secrets. Use npm ci from a lockfile, run npm audit in CI and read the Malicious Package and Dependency Confusion Guide.

Logging and detection

Express logs nothing by default. Add structured request logging (for example a JSON logger middleware) and application events, and make sure the client IP in those logs is the real one.

Get trust proxy right first

The Express documentation sets trust proxy to false by default, so req.ip is the socket address. Behind a load balancer every request then appears to come from the proxy, and a rate limiter keyed on IP will throttle everyone at once. Setting it to true trusts the left-most X-Forwarded-For entry, which a client can forge unless the last proxy overwrites the header. The safer choices are a hop count that matches a single fixed path (for example 1) or the proxy's addresses or subnets ('loopback', 'uniquelocal' or explicit CIDRs). ASVS 5.0 V15.3.4 requires that proxies pass the original IP in fields that cannot be manipulated.

What to log and alert on

Never log session IDs, bearer tokens, the Authorization header or request bodies from login and payment routes. See the JWT and Session Tokens in Code and Logs Guide and the Secure Error Handling and Logging Guide.

Metrics that show the controls work

• Header coverage: percentage of production routes returning CSP, HSTS, X-Content-Type-Options and COOP, checked by an automated scan.
• Cookie compliance: share of session and auth cookies with Secure, HttpOnly, SameSite and a __Host- prefix.
• Patch latency: days from an Express, Node.js or middleware advisory to deployment, against your documented remediation window (ASVS 5.0 V15.1.1).
• Login abuse blocked: rate limit and lockout events per day on authentication routes, trended against successful logins.
• Unprotected routes: count of routes reachable without authentication that are not on the documented public list, from a route inventory test.

Hardening baseline

Recommended middleware order

1. app.disable('x-powered-by') and app.set('trust proxy', ...) matched to your real proxy path.
2. helmet() with an application-specific Content Security Policy.
3. A general rate limiter, plus a stricter one on login, password reset and token endpoints.
4. Body parsers with explicit limits, for example express.json({ limit: '100kb' }), sized to the largest legitimate payload. The OWASP cheat sheet uses limits as low as 1kb for small forms.
5. Session middleware, then authentication, then authorisation routers.
6. Routes.
7. A custom 404 handler and a final error handler that logs the stack server-side and returns a generic message.

What Helmet sets by default

Cross-Origin-Embedder-Policy is not set by default; enable it only if you need cross-origin isolation. The Security Headers Guide covers each header in depth.

Rate limiting choices

The Express team recommends blocking on two signals for login: consecutive failures for the same username and IP, and total failures from an IP over a longer window (their example is 100 failures in a day), and points to rate-limiter-flexible. express-rate-limit is a simpler per-route limiter with windowMs, limit and IETF RateLimit headers through standardHeaders. Choose by deployment:

• Single instance, low risk: express-rate-limit with the default memory store is acceptable.
• Several instances or containers: use a shared store (Redis or similar), or each replica counts separately and the effective limit multiplies.
• Login and recovery endpoints: key on username plus IP as well as IP alone, so distributed credential stuffing against one account is still slowed. Keep IPv6 grouping (express-rate-limit's ipv6Subnet) so one host cannot rotate through a /64.
• Large estates: enforce coarse limits at the edge or API gateway and keep account-aware limits in the app. See the Rate Limiting and API Abuse Guide.

Input, parsing and redirects

• Type checks: query strings can parse into arrays or objects. Express 5 defaults to the simple query parser and express.urlencoded to extended: false; keep those unless you need nested input, and validate types (ASVS 5.0 V15.3.5). Use hpp or explicit handling against parameter pollution (V15.3.7).
• Prototype pollution: never merge request bodies into objects with recursive merge helpers; use schema validation and Map where keys are user controlled (V15.3.6). See the Prototype Pollution Guide.
• Templates: keep auto-escaping on and never compile user input as a template. See the Server-Side Template Injection (SSTI) Guide.
• Redirects: validate the target host with new URL() against an allowlist before res.redirect(), and do not trust Referer as a redirect target now that Express 5 has removed the 'back' shortcut. See the Open Redirect Guide.
• Dangerous functions: no eval(), no child_process.exec with request data, and regular expressions checked for catastrophic backtracking (ReDoS), with eslint-plugin-security in CI.

Phased rollout

1. Inventory: list Express and Node.js versions, middleware, routes and which are public. Upgrade any 3.x service immediately and bring 4.x to at least 4.21.2, or plan the move to 5.
2. Low-risk wins: disable X-Powered-By, add custom error handlers, set body limits and fix trust proxy. Verify req.ip in logs from a known test client.
3. Headers in report mode: deploy Helmet with contentSecurityPolicy: { reportOnly: true }, collect violations for one or two release cycles, then enforce.
4. Sessions: move to a production store, rename the cookie, set Secure and SameSite, and add regenerate on login. Expect a one-time logout when the cookie name changes; schedule it.
5. Rate limits: start with logging-only thresholds, compare against real traffic, then enforce on authentication routes first.
6. Rollback: keep each change behind configuration so a header or limiter can be relaxed without a code release, and keep the previous session secret in the array during rotation so a rollback does not invalidate sessions.

Framework mapping

Common misconfigurations

• trust proxy set to true on a directly reachable app: clients forge X-Forwarded-For, bypass IP rate limits and poison audit logs. Match the setting to the real hop count or proxy subnet.
• Secure cookies that silently stop working: cookie.secure: true behind a TLS-terminating proxy without trust proxy means express-session never sets the cookie, and teams "fix" it by turning Secure off.
• MemoryStore in production: sessions vanish on restart, memory grows without bound and multiple replicas disagree about who is logged in.
• Routers mounted before authentication: a new router added near the top of app.js is public by accident. Test unauthenticated access to every route in CI.
• Helmet added, CSP disabled: teams turn off contentSecurityPolicy to stop breakage and never return to it, losing the main XSS mitigation. Use report-only instead. See the Cross-Site Scripting (XSS) Prevention Guide.
• Stack traces to users: the default error handler or a res.send(err) leaks paths and library versions. Use a final handler that returns a generic message.
• Permissive CORS on cookie-authenticated APIs: reflecting any Origin with credentials allowed lets other sites read authenticated responses. See the CORS Misconfiguration Guide.

Practitioner checklist

• Express is on a maintained major with all published security releases applied (4.21.2 or later, or 5.x), and Node.js is on a supported line.
• x-powered-by is disabled and custom 404 and error handlers return no stack traces in production.
• trust proxy matches the real proxy path, verified by checking req.ip in logs.
• Helmet is enabled with an application-specific CSP that was trialled in report-only mode and has a reporting endpoint.
• express-session uses a production store, a non-default cookie name, Secure, HttpOnly, SameSite and a strong rotated secret from a secrets manager.
• Sessions are regenerated on login and destroyed server-side on logout.
• Login, reset and token endpoints have account-aware rate limits backed by a shared store.
• Body parsers have explicit size limits, input is type-checked and schema-validated, and redirects use an allowlist.
• Authentication is applied at router level with a documented public route list tested in CI.
• npm ci, npm audit and a lint step with security rules run on every build.

Standards and references

• Express: Production Best Practices: Security
• Express: Security Updates
• Express: Express Behind Proxies
• Express: Migrating to Express 5
• Express: express-session documentation
• Helmet: Helmet documentation
• OWASP: Node.js Security Cheat Sheet
• OWASP: Application Security Verification Standard 5.0

Related NHI Mgmt Group resources: Node.js Security Guide · Security Headers Guide · Cookie Security Guide · Rate Limiting and API Abuse Guide · Server-Side Template Injection (SSTI) Guide