Cookie security: set attributes to match their purpose

What you can check about a cookie

A cookie might store a language preference or a reference to a login session held on the server. Its name alone cannot reliably establish either its content or its role in authentication. First identify which component sets it and what the application uses it for.

A Set-Cookie header shows what the server sends to the browser. Whether the browser accepts the cookie, how long it retains it and which later requests include it are separate questions. Additional browser rules and user settings may restrict storage or sending. MDN: using cookies

The Web Security Check analyses cookie attributes in the observed Set-Cookie headers of a retrieved response. It does not log in, cover every path, inspect cookies subsequently set through JavaScript or examine the browser's entire cookie store. A cookie that was not observed is therefore confirmed neither absent nor secure. An individual finding can still answer your first configuration question.

Secure, HttpOnly and SameSite serve different purposes

Some browsers treat local development addresses specially for Secure. Such exceptions are not a basis for a public HTTP configuration. For production web applications, HTTPS delivery, including any proxies in front of the application, must match the cookie configuration. MDN: Set-Cookie

For a session cookie used on the server and bound to a single host, the following combination may be suitable:

Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

The value is fictional and the example has not been tested in practice. It assumes HTTPS, a supporting browser and a flow that works with Lax. In addition to being set securely, __Host- requires an explicit Path=/ and prohibits a Domain attribute. The prefix replaces neither HttpOnly nor a deliberate choice of SameSite. In supporting browsers, the less restrictive __Secure- also requires secure setting with Secure, but imposes no additional host/path restrictions like __Host-. These prefixes do not provide general protection against cookie jar overflow.

Distinguish site, host and path

For ordinary HTTP(S) addresses, ‘same-site’ is based on the scheme and registrable domain. This boundary cannot always be identified from the last dot in a name alone: the Public Suffix List also accounts for certain hosting services.

https://app.example.com and https://api.example.com are same-site but have different origins. An origin is defined by scheme, host and port. Switching from HTTPS to HTTP can therefore be cross-site, whereas a different port with the same scheme and registrable domain does not change the site. SameSite thus does not generally exclude a compromised sibling domain. web.dev: same-site and same-origin

Path is not a reliable security boundary between applications on the same host. Domain and path also help determine which existing cookie you modify or delete. RFC 6265: Domain and Path

Choose SameSite and understand its CSRF limitations

Cross-Site Request Forgery exploits, among other things, the browser's ability to attach existing credentials to a request triggered from elsewhere. Whether an application then performs an action also depends on its authentication, authorisation and CSRF checks.

The following table describes only the SameSite condition. It assumes the cookie is already stored, the domain and path match, and no other browser rule prevents it from being sent.

‘Safe HTTP method’ is a protocol term, not a judgement about your application's security. State changes do not belong in a GET request. Even with Lax, additional CSRF countermeasures remain necessary. An absent SameSite attribute is not equivalent to None: browsers may apply a Lax default; a less restrictive variant may allow certain top-level POST requests for recently set cookies. Do not rely on this transitional behaviour. 6265bis-22: SameSite processing

This distinction matters for login, payment and embedding flows. When following an external link, a Strict cookie is not sent on the first cross-site navigation. That does not automatically mean the server-side session has ended or the user must sign in again. None; Secure may be suitable for deliberately required cross-site functions, but does not override browser restrictions on third-party cookies.

Check lifetime and logout separately

Max-Age specifies a lifetime in seconds; Expires specifies a point in time. If both are present, Max-Age takes precedence. A browser may remove a cookie earlier, for example because of its storage policies or a user action.

If neither is present, this is a session cookie in terms of browser storage. The browser determines when a browsing session ends; session restore may reuse cookies after a restart. A ‘Session’ entry therefore proves neither a guaranteed deletion time nor a valid login.

To remove a cookie, the application must match its name, domain/host binding and path, for example using Max-Age=0. Logout must also invalidate the application session on the server. Deleting the cookie in the browser alone does not invalidate a session identifier that has already been copied. MDN: removing cookies, OWASP: session management

Work through configuration in three steps

1. Identify the required flow and responsible component

Record the cookie's purpose, the application setting it, the required hosts/paths, lifetime and JavaScript access. Pay particular attention to external sign-in, payment redirects and embedded content. A session cookie used on the server can receive HttpOnly; a preferences cookie intentionally read by JavaScript needs a different decision.

Set attributes where the cookie originates wherever possible. A reverse proxy can add attributes to upstream cookies, but does not automatically know their purpose in the application.

2. Set targeted cookie options

The following Nginx fragment modifies the cookie named session set by the upstream. It requires proxy_cookie_flags, available from Nginx 1.19.3, and an appropriate proxy context:

location / {
    proxy_pass http://backend;
    proxy_cookie_flags session secure httponly samesite=lax;
}

backend is a placeholder for your configured upstream. This fragment has not been run. It changes neither the cookie name nor, automatically, its Domain, Path or lifetime, and does not cover cookies created later in the browser. Where several rules apply, the first matching rule is used; also check inherited configuration. Do not apply a SameSite rule to all cookies without checking their requirements. Nginx: proxy_cookie_flags

For an already configured express-session middleware, the following options can be supplied as the cookie option:

const cookieOptions = {
  secure: true,
  httpOnly: true,
  sameSite: 'lax',
  path: '/',
};

This is only the cookie options object, not a complete Express application. It does not include the secret, session store or remaining middleware configuration. With secure: true, the application must recognise the request as HTTPS. Behind a reverse proxy, the trust configuration must match the actual setup; indiscriminate proxy trust is not a safe default. This example has not been tested in practice either. Express: express-session

3. Check the response and browser flow again

For an initial look at the headers of a GET response, you could use the following on a target you are authorised to examine:

curl -sS -D - -o /dev/null https://example.com/login

The address is a placeholder. This command has not been run; it does not log in, follow redirects or reproduce browser cookie rules. A HEAD request using -I is a different request, and its response need not set the same cookies. Check the response that actually creates the relevant cookie, for example after an authorised login. curl: documented options

Then inspect the stored attributes, blocking reasons and cookies on a later request in the browser. Also compare logout and the affected external flows.

Document a technical finding clearly

Record the cookie's purpose, the flow examined, browser context, observed attributes, open questions and follow-up checks. Session values do not belong in public handover documentation. The attributes can support technical safeguards; they establish neither complete security nor lawfulness or GDPR compliance.

Whether requirements under PCI DSS, NIS2 or other rules apply in a particular case, and which ones, needs separate assessment. A cookie check is not complete evidence for that assessment. Technical settings alone cannot determine, in particular, whether a cookie requires consent.

Further checks and configuration guidance

If checking a public response can answer your next question, you can open the Web Security Check. The login and browser checks described above remain a separate step.