cookie-parser in Express: Security Guide and Best Practices

The cookie-parser npm middleware is safe when you run version 1.4.7 or later and treat signed cookies as integrity protection only — the common failures are stale transitive cookie versions and teams mistaking signing for encryption. cookie-parser is one of the oldest pieces of Express middleware still in daily use, and its very simplicity is why misconfigurations survive code review. This guide covers what it actually guarantees, the 2024 advisory that touched its dependency chain, and the hardening flags that belong on every cookie you set.

What cookie-parser does — and does not do

The middleware does exactly two things: parses the Cookie request header into req.cookies, and, if you pass a secret, verifies signed cookies into req.signedCookies.

const express = require('express');
const cookieParser = require('cookie-parser');

const app = express();
app.use(cookieParser(process.env.COOKIE_SECRET));

app.get('/prefs', (req, res) => {
  const theme = req.signedCookies.theme;  // tamper-evident
  const locale = req.cookies.locale;      // attacker-controllable
  res.json({ theme, locale });
});

Three properties to internalize:

• Signing is integrity, not confidentiality. A signed cookie's value is plainly readable by the user; the HMAC only proves your server produced it. Never put secrets in a signed cookie on the theory that signing hides them.
• req.cookies is untrusted input. Everything in it came from the client verbatim. Validate it like a query parameter.
• Failed signatures degrade silently. A tampered signed cookie shows up as false in req.signedCookies, not as an exception. If your code reads the unsigned req.cookies copy of the same name as a fallback, you have quietly built a signature bypass.

The 2024 dependency advisory: CVE-2024-47764

cookie-parser performs parsing via the low-level cookie package, and that package received CVE-2024-47764 in October 2024. Versions of cookie before 0.7.0 accepted out-of-bounds characters in cookie names, paths, and domains. If an application ever passed user-influenced strings into those fields when serializing cookies, an attacker could smuggle separators and overwrite other attributes — the advisory's example turns a cookie name into a vehicle for setting an entirely different cookie.

The Express ecosystem responded with coordinated bumps: cookie-parser 1.4.7 (November 2024) moved to the patched cookie 0.7.x line. Your action items:

npm ls cookie cookie-parser
npm audit --omit=dev

If cookie-parser resolves below 1.4.7, or a stray direct cookie dependency resolves below 0.7.0, upgrade. And regardless of version: never feed unvalidated user input into cookie names, domains, or paths — the patched validator rejects hostile input, but the design smell remains yours.

Signed cookies done properly

The secret you pass to cookieParser(secret) is the entire security of req.signedCookies, so manage it like a credential:

• Load it from a secret manager or environment, never source control.
• Make it long and random (32+ bytes); it feeds an HMAC, not a password checker.
• Rotate it. cookie-parser accepts an array of secrets — new secret first for signing, old ones retained for verification during the rotation window:

app.use(cookieParser([process.env.COOKIE_SECRET_CURRENT,
                      process.env.COOKIE_SECRET_PREVIOUS]));

And keep scope clarity: if you use express-session, the session cookie is signed by that middleware with its own secret; cookie-parser is unnecessary for it. Running both with different secrets on overlapping cookies is a classic source of intermittent "signature invalid" bugs.

Set-cookie hardening flags

Parsing is half the story; the cookies you set need attributes that limit what a network attacker or injected script can do with them:

res.cookie('session_hint', value, {
  httpOnly: true,   // invisible to document.cookie — blunts XSS theft
  secure: true,     // HTTPS only
  sameSite: 'lax',  // CSRF mitigation; 'strict' where UX allows
  signed: true,
  maxAge: 8 * 60 * 60 * 1000,
  path: '/app',     // narrowest path that works
});

Add the __Host- prefix for your most sensitive cookies (__Host-session): browsers then enforce Secure, no Domain attribute, and root path, which kills a whole class of subdomain-planting attacks. None of this is specific to npm cookie-parser, but the middleware is usually where cookie conventions get set for an Express codebase, so codify the defaults next to it.

Testing your cookie handling

Cookie bugs are runtime bugs, which makes them a good fit for dynamic testing. Useful checks to automate:

1. Request each authenticated endpoint with a tampered signed cookie and assert a clean 401/redirect, not a fallback to unsigned data.
2. Confirm every Set-Cookie in responses carries HttpOnly/Secure/SameSite as policy requires — a DAST scanner will flag missing attributes across the whole surface faster than grepping the codebase, since flags are often set per-route.
3. Verify no endpoint reflects req.cookies values into HTML without encoding; cookie values are an underrated XSS source because developers assume "we set them."

On the dependency side, lockfile scanning catches the transitive cookie version drift described above — that is standard SCA territory, and worth wiring into CI once rather than re-litigating per release.

When you do not need cookie-parser at all

Modern Express apps sometimes cargo-cult the middleware. You can skip it when:

• You only use express-session (it parses its own cookie).
• You only set cookies via res.cookie() and never read them (Express serializes without cookie-parser).
• You are on a framework layer (NestJS with Fastify, for example) that has its own cookie plugin.

Fewer middleware layers means fewer packages in the audit queue. If it stays, pin it current and move on — it is a small, stable, actively maintained package with a good track record.

FAQ

Is cookie-parser still necessary in Express?

Only if you read cookies from requests. Setting cookies with res.cookie() works without it, and express-session handles its own cookie parsing. If you do read cookies, it remains the standard, maintained choice — use 1.4.7 or later.

Are signed cookies encrypted?

No. Signing appends an HMAC that makes tampering detectable; the value itself remains readable by the client. Do not store secrets in cookies on the strength of signing — store an opaque identifier and keep the data server-side.

What was CVE-2024-47764 and does it affect cookie-parser?

It was a validation gap in the underlying cookie package (before 0.7.0) allowing out-of-bounds characters in cookie names, paths, and domains, which could be abused to alter other cookie fields. cookie-parser 1.4.7 ships the patched dependency; verify with npm ls cookie.

Should I use SameSite strict or lax?

lax is the pragmatic default: it blocks cross-site POST-driven CSRF while keeping top-level navigation logins working. Use strict for high-value cookies where a re-authentication hop on external links is acceptable.