Medium severity

Insecure Cookies

Cookies missing `Secure`, `HttpOnly`, or `SameSite` flags can be stolen or abused.

Business risk

1. Missing `Secure`: Plaintext theft. 2. Missing `HttpOnly`: XSS theft. 3. Missing `SameSite`: CSRF attacks.

Technical details

Always enforce `SameSite=Lax` (or Strict) for session cookies. Use `__Host-` prefix for maximum security.

How to detect it

Log in, inspect the `Set-Cookie` response headers, and verify every session or auth cookie has `Secure`, `HttpOnly`, and `SameSite`. Missing flags on ancillary cookies (preferences, language) are lower priority but should still be audited.

Dump Set-Cookie headers

curl -sI -X POST -d "user=x&pass=x" https://yourdomain.com/login | grep -i set-cookie

Inspect all cookies in the browser

DevTools → Application → Cookies → your domain → check Secure / HttpOnly / SameSite columns

Common pitfalls

Setting `SameSite=None` without `Secure`. Modern browsers silently reject this combination, and the cookie is never stored. If you need cross-site use, set both.
Using the `__Host-` prefix but also specifying a `Domain` attribute. `__Host-` requires no `Domain` (the cookie is bound to the exact origin). Adding `Domain` invalidates the prefix and the cookie is rejected.
Forgetting `HttpOnly` on session cookies because a frontend script wants to read them. If the frontend needs it, use a different cookie - never expose the session token to JavaScript.
Choosing `SameSite=Strict` for the primary session cookie and then wondering why users land logged out when they arrive from a link in an email. Use `Lax` for sessions; keep `Strict` for sensitive secondary tokens (e.g., CSRF).
Not rotating session cookies on login. Fixed session IDs allow session-fixation attacks. Issue a fresh cookie on every authentication event.

Remediation guide

Set-Cookie: s=1; Secure; HttpOnly; SameSite=Lax

text

External references

MDN: Set-Cookie

Frequently asked questions

Lax or Strict for session cookies?

`Lax` for the primary session cookie. It permits top-level navigations (so clicking an email link that lands on your site still sees the session) but blocks cross-site POSTs, which is the CSRF vector. `Strict` breaks that link flow and causes user confusion.

__Host- or __Secure- prefix?

`__Host-` is stricter: requires Secure, requires Path=/, forbids Domain. Use it for the session cookie. `__Secure-` only requires Secure; use it when you need a Domain attribute (e.g., cookies shared across subdomains).

Do I need HttpOnly on every cookie?

On every cookie the frontend does not need to read from JavaScript. Session IDs, auth tokens, and CSRF tokens: yes. UI preferences like theme or language: no - those benefit from JS access.

Keep going

High severity · Transport

Related guide

Missing Content Security Policy (CSP)

High severity · Content

Related guide

Server Information Leakage

Low severity · Misc

Deep guide

HSTS: A Complete, Rollback-Safe Setup Guide

The max-age ramp, subdomain audit and preload submission - in the order they won't burn you.

Free tool

Cookie Security Checker

Audit every Set-Cookie on the page - the flags that matter, in one scan.

Verify your fix

Applied the configuration change? Run a live scan to confirm the vulnerability is patched.

How to detect it

Dump Set-Cookie headers

curl -sI -X POST -d "user=x&pass=x" https://yourdomain.com/login | grep -i set-cookie

Inspect all cookies in the browser

DevTools → Application → Cookies → your domain → check Secure / HttpOnly / SameSite columns

Common pitfalls

Setting `SameSite=None` without `Secure`. Modern browsers silently reject this combination, and the cookie is never stored. If you need cross-site use, set both.

Using the `__Host-` prefix but also specifying a `Domain` attribute. `__Host-` requires no `Domain` (the cookie is bound to the exact origin). Adding `Domain` invalidates the prefix and the cookie is rejected.

Forgetting `HttpOnly` on session cookies because a frontend script wants to read them. If the frontend needs it, use a different cookie - never expose the session token to JavaScript.

Choosing `SameSite=Strict` for the primary session cookie and then wondering why users land logged out when they arrive from a link in an email. Use `Lax` for sessions; keep `Strict` for sensitive secondary tokens (e.g., CSRF).

Not rotating session cookies on login. Fixed session IDs allow session-fixation attacks. Issue a fresh cookie on every authentication event.

Frequently asked questions

Lax or Strict for session cookies?

__Host- or __Secure- prefix?

Do I need HttpOnly on every cookie?

On every cookie the frontend does not need to read from JavaScript. Session IDs, auth tokens, and CSRF tokens: yes. UI preferences like theme or language: no - those benefit from JS access.