Secure, HttpOnly, SameSite: What Twenty Front Pages Attach to Their Cookies

A cookie is a short line the server asks a browser to remember and send back. Three optional attributes can be attached to it, each addressing a different security risk.

They cost nothing to add. Measured across twenty large front pages, two of the three are common and the third is missing more often than it is present – and it is the one that matters once something has already gone wrong.

Three words, three different dangers

Secure means the cookie travels only over an encrypted connection. Without it, a single request over plain HTTP – a mistyped address, an old bookmark, a link in an email – hands the value to anyone listening on the same network.

HttpOnly means scripts in the browser cannot read the cookie. It exists for the case where a page ends up running code nobody intended: an injected script, a compromised third-party library, a bad advert. Without this word, such code reads the session cookie in a single line.

SameSite controls whether the cookie is sent along when the request comes from a different site. It is the defence against a hidden form on a foreign page carrying out an action in the name of whoever happens to be logged in.

Three doors, and none of the three helps with what the other two guard.

What was measured

Twenty large front pages were opened once each on 2 September 2026, following redirects, accepting nothing and clicking nothing. All twenty answered with status 200.

Counted was every Set-Cookie line exactly as it arrived: the cookies set before any consent, which is precisely the set a visitor collects by doing nothing at all.

What a consent banner adds afterwards is a separate question and a much larger number. This is the floor, not the ceiling.

Twelve of twenty set nothing

The largest single group in the measurement sets no cookie whatsoever on a first visit: twelve of the twenty.

Those are mostly project and documentation sites – the kind of page that shows text and has nothing to remember. It deserves stating plainly, because the flags only become a question after the decision to set a cookie has been taken, and that decision is skipped more often than any of the three words is used.

The remaining eight sites set 29 cookies between them, ranging from a single one to ten on a single page.

Secure is the rule, HttpOnly the exception

Of those 29 cookies, 23 carried Secure, 17 carried SameSite and 12 carried HttpOnly.

The ranking is no accident. Secure is close to automatic by now: browsers have pushed it for years, and frameworks add it by default on an encrypted site. SameSite arrived with a default value, so a cookie without the word is treated as though it had asked for the middle setting – the word is often absent while the protection is not.

HttpOnly has no such default. A cookie without it is readable by every script on the page, and nothing supplies the word unless somebody writes it.

Three cases in detail

Wikipedia set the most and guarded them best: ten cookies, every single one Secure, six of them HttpOnly. Only four carried SameSite, which fits the pattern above exactly.

The New York Times set nine, and not one of them was HttpOnly. Five were Secure and five carried SameSite, so the protections that stop a cookie leaving by the wrong route were partly in place, while the one that stops a script reading it was absent altogether.

And two sites set a single cookie carrying none of the three words: apple.com and php.net. One cookie each, no encryption requirement, readable by any script, sent along from anywhere.

What a missing HttpOnly actually costs

The three words are not equally replaceable.

Without Secure, a cookie leaks on an unencrypted request – and on a site that redirects everything to HTTPS and sends a strict transport header, that request largely does not happen.

Without SameSite, the browser applies its own default, which blocks the worst case unaided.

Without HttpOnly, nothing steps in. The cookie is readable by any code running on the page, and code running on a page is not a rare event: it is the ordinary outcome of one third-party script being compromised somewhere far away from the site that embedded it.

Which is why the ranking measured here runs the wrong way round. The word added least often is the one nothing else covers.