Securing Session Cookies: Secure, HttpOnly, SameSite

One traffic-light item covering three different attacks

In reports about security headers the cookie usually sits at the margin. The article on response headers and what they do covers HSTS, Content-Security-Policy, X-Frame-Options and Referrer-Policy - that is, what the server says about the response itself. The cookie attributes travel in the same response but belong to a different class: they do not describe the document, they describe the badge the browser sends along with every request that follows.

In a security scan that difference disappears. There you get one line - cookies with the Secure attribute, met or not met - with a single-digit deduction from the overall score. That one line rolls up three independent questions: whether the identifier can leave over an unencrypted connection, whether an injected script can read it, and whether a foreign sender can make the browser attach it. Three attributes, three attack paths, one point.

If you take the deduction seriously, you need to know which of the three questions is open. The XICTRAQ security scan reads out each cookie individually and records the name, Secure, HttpOnly and the SameSite value separately - precisely so the traffic-light dot turns back into a diagnosis.

Secure: the attribute against the cleartext line

RFC 6265 describes Secure tersely: the attribute limits the scope of the cookie to secure channels, and the browser only attaches it to a request that runs over a secure channel - typically HTTP over TLS (RFC 6265). Where the attribute is missing, the MITRE weakness catalogue treats that as a class of its own: the Secure attribute for sensitive cookies in HTTPS sessions is not set, CWE-614 (MITRE CWE).

The most common objection is that the site runs entirely over HTTPS anyway. The OWASP session management cheat sheet contradicts that explicitly: forcing an application onto HTTPS does not protect the session identifier as long as the Secure attribute is missing - the browser can be induced to disclose the identifier over an unencrypted connection (OWASP). An attacker on the same network injects a reference to http:// and reads the identifier out of that request. With the announced HTTPS warning in Chrome from October 2026 this detour becomes more visible, but it does not disappear.

The attribute is set rarely all the same: 24 percent of first-party cookies carry it (HTTP Archive Web Almanac). For third-party cookies the figure sits close to one hundred percent, though not out of diligence - anyone who wants to set SameSite=None has to send Secure with it, otherwise the browser rejects the cookie (HTTP Archive Web Almanac).

HttpOnly: the line between script and session

HttpOnly limits the scope of the cookie to HTTP requests. The browser omits it when access happens through an interface that is not an HTTP request - in particular through the interface that hands cookies to scripts (RFC 6265). In practice that means document.cookie does not see the cookie, an injected script cannot read the session identifier and cannot ship it to a foreign recipient. The weakness catalogue lists the omission as CWE-1004: the product stores sensitive information in a cookie without the HttpOnly flag (MITRE CWE).

That boundary has a clearly named edge. OWASP notes that HttpOnly protects the confidentiality of the cookie: an attacker cannot use it outside the script context - but the requests an injected script triggers in the victim browser still carry the cookie, because the browser attaches cookies when sending requests (OWASP). HttpOnly prevents the identifier from leaking, not its use inside the running browser. That is why a strict Content-Security-Policy remains worthwhile alongside it: it starts one stage earlier.

The attribute is even rarer than Secure: 12 percent of first-party and slightly more than 26 percent of third-party cookies carry it (HTTP Archive Web Almanac). That third parties lead here says little about diligence - their cookies are simply read less often by first-party page script. For your own session identifier, OWASP classifies HttpOnly as mandatory (OWASP).

SameSite: what the browser does with foreign senders

SameSite is the youngest of the three attributes and the only one that governs not who may read the cookie but when the browser attaches it at all. The draft version of the cookie specification describes three values (RFC 6265bis):

• Strict - the cookie is sent only with requests that originate from the same site (RFC 6265bis). A link from a foreign domain lands in a signed-out view.
• Lax - the cookie is sent with same-site requests and, beyond that, with top-level navigations that come from a foreign site (RFC 6265bis). A link from a search engine lands in a signed-in view, while an embedded form on a foreign domain does not get the cookie.
• None - the cookie is sent with same-site and cross-site requests (RFC 6265bis). That value requires Secure; without an encrypted connection the browser rejects the cookie.
• If some other value appears in the line, the browser treats it like Lax (RFC 6265bis). A typo in the attribute therefore does not surface as an error but silently as a change of rule.

The case without any value behaves like Lax in widely used browsers too, but in a more permissive variant: cookies are also sent on POST requests as long as they were set no more than two minutes before the request (MDN). Relying on the default therefore means relying on a variant that differs between browser and version. OWASP advises setting the value explicitly for session cookies rather than depending on the browser default (OWASP).

Adoption is skewed accordingly. In the desktop crawl, 3 percent of first-party cookies carry SameSite=Strict, 19 percent Lax, 11 percent None and 66 percent no value at all (HTTP Archive Web Almanac). Among third-party cookies None is close to one hundred percent, because otherwise they would not be sent in a foreign context (HTTP Archive Web Almanac). The weakness catalogue lists the missing or insecurely set attribute as CWE-1275 and names cross-site request forgery as the consequence where no further protection applies (MITRE CWE). Anyone who has hunted down a misconfigured cross-origin permission knows the neighbourhood of the question.

The table makes the division of labour visible: no attribute replaces another. OWASP puts it especially plainly for SameSite - it is a defence in depth against cross-site request forgery and not a substitute for a token (OWASP). And because browsers have shifted the defaults several times over the years, the state belongs in a check that runs with every release - the shorter Chrome shipping cadence from 2026 narrows that window further.

The successor specification is still a draft

One detail that rarely surfaces in audit reports: SameSite is not described in any published RFC. RFC 6265 dates from April 2011 and defines only Secure and HttpOnly out of the three attributes (RFC 6265). Everything beyond that - SameSite, the name prefixes, the behaviour on unknown values - sits in draft-ietf-httpbis-rfc6265bis, most recently in revision 22 of 1 December 2025 (IETF). The document is in the RFC Editor queue and is meant to obsolete RFC 6265 once it is approved (IETF).

Two things follow for practice. First, the dependable reference point is the behaviour of shipped browsers rather than a finished document: changes to defaults arrive through browser releases, not through a new revision of the specification. Second, the wording in your own security concept matters. If you write SameSite as a requirement, cite the draft cleanly and not RFC 6265, which does not contain the attribute.

Name prefixes bind the cookie to its properties

A set attribute says nothing about whether it stays set. A subdomain can overwrite a cookie of the same name, and an attacker with access to an insecure channel cannot read a Secure cookie but can overwrite it - RFC 6265 names that limitation in the section on Secure itself and records that the attribute protects confidentiality and not integrity (RFC 6265). The name prefixes close exactly that gap by having the browser enforce the properties through the name.

Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/

__Host-    enforces Secure, Path=/ and the absence of a Domain attribute
__Secure-  enforces Secure

If the name begins with __Secure-, a conforming browser accepts the cookie only when it carries the Secure attribute. If it begins with __Host-, Path=/ must be set as well and the Domain attribute must be omitted - which binds the cookie to exactly one host so it does not travel across subdomains (RFC 6265bis). OWASP recommends __Host- explicitly for session identifiers (OWASP). What the delivered response looks like as a whole is shown by the header tool for a single address.

Where the attributes get lost in operation

Cookie attributes are not a state you establish once. They arise at different points in the delivery chain, and each of those points can remove them again without producing an error. Six patterns show up particularly often.

• Framework defaults: many frameworks set Secure only when they recognise the request itself as secure. Behind a reverse proxy that terminates TLS they see a cleartext request and omit the attribute.
• Rewriting intermediaries: a proxy or a delivery layer may modify Set-Cookie. What the application sends is not necessarily what arrives in the browser.
• Sign-in through an insecure response: if the session is already set in the response to the http request and only redirected afterwards, the identifier has already travelled in cleartext once.
• Secondary applications on subdomains: a help portal, a booking module or a preview environment sets its own cookies with its own defaults. Without __Host- they share the name space with the main application.
• Divergent environments: the staging environment runs without a certificate, the attribute is switched off there, and the switch travels into production with the configuration.
• A default that changes: if a browser changes its behaviour for a missing SameSite, the behaviour of your own application changes without anyone having shipped a thing.

What the six cases share is that they do not stand out in the application itself. Sign-in keeps working, the page loads, no log reports anything. They only become visible when someone looks at the delivered response - the way checking the sign-in path and the checkout looks at the path itself and not only at the home page.

Consent is a separate question

Security attributes and consent get mixed up regularly even though they answer different questions. Under section 25 paragraph 1 of the German TDDDG, storing information in the end-user terminal equipment is permitted only with that user consent (TDDDG). Paragraph 2 number 2 exempts what is strictly necessary for the provider of a digital service to make available a digital service expressly requested by the user (TDDDG). A cookie carrying the sign-in usually falls under that. What the draft of the 2026 cookie banner reform wants to change concerns obtaining consent, not securing the session.

The attributes themselves are not a legal basis and do not replace one. They lower the risk that an identifier which is permissible anyway ends up in foreign hands. Conversely, granted consent does not make a cookie without Secure any safer. Separating the two layers cleanly leads to a shorter list of consent-requiring cookies during the implementation of consent and to a clearer justification for the rest.

Checking cookie attributes continuously

The state can be measured without much effort: every response that opens a session carries the attributes in the Set-Cookie line. The security scan reads them out per cookie - name, Secure, HttpOnly and the SameSite value appear separately in the result instead of collapsing into a single traffic-light dot. Seven steps turn that into a dependable routine.

1. List all session cookies: not only the one belonging to the main application. Secondary applications, preview environments and subdomains set their own identifiers with their own defaults.
2. Record the three attributes per cookie: Secure, HttpOnly and the SameSite value belong in the list individually, not as one combined verdict.
3. Choose the SameSite value deliberately: Strict for identifiers that carry privileges, Lax where an external link should land in a signed-in view. None is a decision that needs a reason, not a default.
4. Keep a token against cross-site request forgery: SameSite works alongside it and not in its place (OWASP).
5. Introduce name prefixes where no rework is needed: __Host- for session identifiers, __Secure- where subdomains need the cookie (RFC 6265bis).
6. Include the delivery chain: what gets measured is the response that arrives in the browser, not the one the application produces.
7. Have changes reported: a vanished attribute is an event and not a state - it belongs in a notification when it disappears, not in the next report.

The last point is what makes the difference in practice. A monthly report finds a missing HttpOnly up to four weeks after the change. A notification on the channel you prefer finds it on the day it ships.

For a first look without an account, the cookie scan for a single address is enough. It shows which cookies are set before consent and which attributes hang off them - and therefore which of the three questions from this article is open in your case. If you want to know which pages are in the measurement at all, the article on the coverage of your own page inventory shows the way there.