Script Valley
HTTP & The Web: How It Actually Works
Web Security EssentialsLesson 6.5

Cookie security: HttpOnly, Secure, SameSite attributes explained

HttpOnly cookie flag, Secure flag, SameSite Strict vs Lax vs None, cookie scope Domain and Path, session fixation, cookie theft via XSS, __Host- prefix

Hardening Cookies

Cookie security attributes diagram

Session cookies are the keys to your application. Three attributes — HttpOnly, Secure, SameSite — dramatically reduce the attack surface for session theft and request forgery.

The secure cookie

Set-Cookie: session=abc123;
  HttpOnly;           # JavaScript cannot read this cookie (blocks XSS theft)
  Secure;             # Only sent over HTTPS connections, never HTTP
  SameSite=Strict;    # Not sent on cross-site requests (blocks CSRF)
  Path=/;             # Applies to all paths on this origin
  Max-Age=3600        # Expires after 1 hour

Attribute breakdown

HttpOnly: Removes the cookie from document.cookie entirely. An XSS payload executing on the page cannot read or steal it. The browser still sends it automatically with every HTTP request — it is just not accessible from JavaScript.

Secure: The browser transmits the cookie only over HTTPS. Without this, the session token can be captured in plaintext on any unsecured network.

SameSite=Strict: The cookie is not sent on any cross-site request — not even when a user clicks a link from another site to yours. Use Lax when the cookie must work with top-level navigations from external links (e.g., OAuth return URLs).

The __Host- prefix

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

The __Host- prefix is a browser-enforced security contract requiring: the Secure flag must be present, no Domain attribute is allowed, and Path must be /. This prevents a compromised subdomain from setting or overwriting cookies for the parent domain — a common attack vector in multi-tenant applications.