Frontend Beauty
ESC

Type to search the knowledge base.

Secure Cookie Flags

HttpOnly, Secure, SameSite, Path, Domain, and Priority: set session cookies so XSS and CSRF have less room.

intermediate3 min read
  • security
  • cookies
  • httponly
  • samesite
  • session

Cookie flags are one of the highest-leverage frontend-adjacent security controls. A session cookie without HttpOnly/Secure/SameSite turns small XSS or CSRF mistakes into account takeover.

Docs: MDN Set-Cookie, SameSite explained, OWASP Session.

Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=86400
Flag Purpose
HttpOnly Not readable from document.cookie (mitigates token theft via XSS)
Secure Only sent over HTTPS
SameSite=Lax/Strict/None Cross-site sending rules (CSRF posture)
Path URL path prefix that includes the cookie
Domain Hosts that receive it (prefer host-only default)
Max-Age / Expires Lifetime
Priority Chrome eviction hint (non-standard-ish)
Partitioned CHIPS for third-party contexts

SameSite quick guide

Value Use when
Strict Max CSRF resistance; may break return-from-external flows
Lax Good default for many session cookies
None; Secure Truly cross-site (embeds, some OAuth); CSRF risk rises

Domain pitfalls

Set-Cookie: session=...; Domain=example.com

Shares cookie with all subdomains — only if every subdomain is trusted. Prefer host-only cookies (omit Domain) for app.example.com sessions.

Document.cookie vs HttpOnly

// Cannot read HttpOnly session
console.log(document.cookie); // missing session=

CSRF tokens sometimes live in a non-HttpOnly cookie (double-submit) while session stays HttpOnly — understand the pattern before copying.

Prefixes

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

__Host- requires Secure, Path=/, no Domain — harder to misuse. __Secure- requires Secure.

Frontend checklist

  1. Auth cookies: HttpOnly + Secure + SameSite.
  2. No secrets in non-HttpOnly cookies without reason.
  3. HTTPS everywhere — mixed content.
  4. Logout clears cookies server-side (Max-Age=0).
  5. Coordinate with CSRF strategy — CSRF.

Interview out-loud

“Session cookies should be HttpOnly, Secure, and SameSite=Lax or Strict. Host-only beats Domain=parent unless subdomains need sharing. SameSite=None is only for deliberate cross-site cases with Secure.”

Reviewer prompts

  • What is the asset (session, PII, money movement)?
  • What is the attacker capability (web, XSS, network, dependency)?
  • Which control fails closed if misconfigured?
  • Is the server still enforcing authz?
  • Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides