Cookie Security: Secure, HttpOnly and SameSite

Two clarifications:

• HttpOnly does not fix the cross-site-scripting flaw itself, which can still do other harm; it protects the token specifically even where such a flaw exists. Fixing the flaw is still necessary (the XSS chapters).
• HttpOnly applies to cookies. A token kept in other browser storage that scripts read is not protected by it, which is an argument for holding session tokens in HttpOnly cookies rather than in script-accessible storage.

SameSite: not sent from other sites

The SameSite attribute controls whether the browser sends the cookie on requests that originate from a different site. It has values that range from sending the cookie only on requests from the same site, through a middle setting that sends it on top-level navigations but not on background cross-site requests, to sending it always (the old default).

The route it closes is cross-site request forgery, the subject of the next chapter. That attack relies on the browser automatically attaching the session cookie to a request that a different, malicious site caused the victim's browser to make, so that the request arrives authenticated. SameSite limits exactly this: if the cookie is not sent on cross-site requests, a request forged by another site arrives without the session cookie and is not treated as authenticated, so the forgery fails.

SameSite is why the next chapter can say the attack is substantially mitigated by a cookie attribute; it is treated fully there. For now, it is the third of the three attributes, closing the third route.

The three together

The attributes map cleanly to three of the block's attack routes:

A session cookie should have all three set appropriately (Secure, HttpOnly, and a restrictive SameSite), plus sensible scope attributes (limiting the cookie to the paths and domains that need it) and an expiry that supports session timeout. Setting them is configuration, and their absence is a finding precisely because it is so easily fixed and so commonly overlooked.

A note on completeness: these attributes protect the cookie, but they are not the whole of session security. Strong random tokens (against prediction), token regeneration at login (against fixation), and the full defences of the next-but-one chapter are also required. The attributes close three routes; they do not close prediction or fixation, which is why the block does not end here.

A worked example, framed defensively

An assessor inspects the session cookie's attributes, a quick and high-value check.

• The session cookie lacks Secure, and the site has an HTTP endpoint. Finding: sniffing exposure; the cookie can be sent in the clear. Fix: set Secure.
• The cookie lacks HttpOnly, and the site has a cross-site-scripting flaw. Finding: the token can be stolen by injected script. Fix: set HttpOnly (and fix the XSS).
• The cookie has no SameSite attribute (so it is sent on cross-site requests), and the site performs state-changing actions on simple requests. Finding: exposure to cross-site request forgery. Fix: set a restrictive SameSite and add anti-forgery tokens (next chapter).
• The cookie's expiry is set far in the future with no inactivity timeout. Finding: a stolen token is useful for a long time. Fix: add inactivity and absolute timeouts.

After setting Secure, HttpOnly and a restrictive SameSite, three routes are closed at once by configuration. The assessor notes that these were the cheapest findings in the report to fix and among the most important, which is the chapter's point.

What beginners get wrong

• Omitting the attributes because the session "works" without them. It works and is needlessly exposed; each attribute closes a real route at no cost.
• Setting one and thinking the cookie is secure. Secure, HttpOnly and SameSite close different routes; all three are needed, plus strong tokens and regeneration for the routes they do not cover.
• Believing HttpOnly fixes cross-site scripting. It protects the token from script theft; the XSS flaw itself must still be fixed and can do other harm.
• Assuming Secure is unnecessary on an all-HTTPS site. It guards against any HTTP endpoint or misconfiguration causing the cookie to be sent in the clear; set it regardless.
• Keeping session tokens in script-readable storage. HttpOnly cannot protect them there; prefer HttpOnly cookies for session tokens.
• Ignoring scope and expiry. A cookie scoped too broadly or lasting too long widens exposure; limit both.

Quick revision

• Secure: cookie sent only over HTTPS, closing the sniffing route (guards against any HTTP endpoint sending it in the clear).
• HttpOnly: cookie invisible to JavaScript, closing the script-theft (XSS) route; protects the token even where an XSS flaw exists, though the flaw must still be fixed. Applies to cookies, not other browser storage.
• SameSite: cookie not sent on cross-site requests, closing the cross-site request forgery route (next chapter).
• A session cookie should set all three, plus restrictive scope and an expiry supporting timeout. They are cheap configuration and commonly missing, hence a frequent, easy finding.
• They close three routes but not prediction or fixation; strong tokens and token regeneration are also required.

Test yourself

1. What does the Secure attribute do, and which route does it close?

It instructs the browser to send the cookie only over an encrypted HTTPS connection and never over plain HTTP, closing the sniffing route. It guards against a session cookie being transmitted in the clear on any unencrypted request, including where a site is mostly HTTPS but has an HTTP endpoint or misconfiguration, so that a network eavesdropper cannot capture it.

1. What does HttpOnly protect against, and what does it not fix?

It prevents client-side JavaScript from reading the cookie, closing the route by which a cross-site-scripting flaw's injected script steals the session token; the browser still sends the cookie, so the session works, but script cannot access it. It does not fix the cross-site-scripting flaw itself, which can still cause other harm and must be remediated separately, and it protects only cookies, not tokens held in script-readable browser storage.

1. What does SameSite restrict, and which attack does that mitigate?

It restricts whether the browser sends the cookie on requests that originate from a different site, so that a cross-site request does not automatically carry the session cookie. This mitigates cross-site request forgery, which relies on the browser attaching the session cookie to a request forged by a malicious site; without the cookie, the forged request is not treated as authenticated and fails.

1. Why are these attributes described as cheap and commonly-found findings?

Because setting them is a matter of configuration rather than code, so they cost almost nothing to apply, yet they are frequently omitted, leaving a session cookie needlessly exposed to sniffing, script theft or cross-site request forgery. Their absence is therefore both a real exposure and among the easiest issues to remediate, which makes them a common and high-value finding in a web assessment.

1. Why do the three cookie attributes not, by themselves, secure a session completely?

Because they close only three routes, sniffing, script theft and cross-site request forgery, and do not address token prediction or session fixation. Securing the session also requires strong, high-entropy tokens to prevent prediction and regeneration of the token at login and on privilege change to prevent fixation, so the cookie attributes are necessary but not sufficient.