What do the HttpOnly, Secure, and SameSite cookie flags do?

A session cookie is a bearer token: whoever holds it is the user. So the attributes you set on it determine how hard it is for an attacker to steal, intercept, or abuse that token. Three flags do most of the work, and each maps to a distinct threat.

HttpOnly — blocks script access

HttpOnly tells the browser to not expose the cookie to JavaScript. document.cookie cannot read it. This is the key mitigation against XSS-based session theft: even if an attacker injects script, they cannot exfiltrate the session cookie. Note it does not prevent XSS itself — the injected script can still make authenticated requests as the user — but it stops the cookie from leaving the browser, which contains the damage.

Secure — HTTPS only

Secure tells the browser to send the cookie only over HTTPS. Without it, a single accidental http:// request (or an attacker forcing one) would transmit the session cookie in cleartext where a network attacker can sniff it. Combined with HSTS, this closes the network-interception path.

SameSite — cross-site sending

SameSite controls whether the cookie rides along on requests originating from other sites:

• Strict — never sent cross-site (strongest CSRF protection, but can disrupt inbound links to authenticated pages).
• Lax — sent on top-level navigations but not cross-site sub-requests/POSTs; a good default that blocks classic CSRF.
• None — always sent, and requires Secure.

Belt and suspenders: name prefixes

The __Host- prefix lets the browser enforce that a cookie is Secure, path /, and not domain-scoped — a guard against subdomain/cookie-fixation tricks.

Interviewers look for the flag-to-threat mapping (HttpOnly/XSS theft, Secure/sniffing, SameSite/CSRF) and the nuance that HttpOnly limits XSS impact rather than preventing XSS.