{"id":13611,"date":"2026-10-21T07:35:00","date_gmt":"2026-10-21T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13611"},"modified":"2026-10-09T22:56:24","modified_gmt":"2026-10-09T20:56:24","slug":"secure-httponly-samesite-what-twenty-front-pages-attach-to-their-cookies","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/tutorials-en\/secure-httponly-samesite-what-twenty-front-pages-attach-to-their-cookies\/","title":{"rendered":"Secure, HttpOnly, SameSite: What Twenty Front Pages Attach to Their Cookies"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

\n\"Twelve
Of 29 cookies: 23 carried Secure, 17 SameSite, 12 HttpOnly.<\/figcaption><\/figure>\n

Three words, three different dangers<\/h2>\n

Secure<\/code> 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.<\/p>\n

HttpOnly<\/code> 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.<\/p>\n

SameSite<\/code> 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.<\/p>\n

Three doors, and none of the three helps with what the other two guard.<\/p>\n

What was measured<\/h2>\n

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.<\/p>\n

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

What a consent banner adds afterwards is a separate question and a much larger number. This is the floor, not the ceiling.<\/p>\n

Twelve of twenty set nothing<\/h2>\n

The largest single group in the measurement sets no cookie whatsoever on a first visit: twelve of the twenty.<\/p>\n

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.<\/p>\n

The remaining eight sites set 29 cookies between them, ranging from a single one to ten on a single page.<\/p>\n

\n\"A
\n<\/figure>\n

Secure is the rule, HttpOnly the exception<\/h2>\n

Of those 29 cookies, 23 carried Secure<\/code>, 17 carried SameSite<\/code> and 12 carried HttpOnly<\/code>.<\/p>\n

The ranking is no accident. Secure<\/code> is close to automatic by now: browsers have pushed it for years, and frameworks add it by default on an encrypted site. SameSite<\/code> 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.<\/p>\n

HttpOnly<\/code> 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.<\/p>\n

Three cases in detail<\/h2>\n

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

The New York Times set nine, and not one of them was HttpOnly<\/code>. Five were Secure<\/code> and five carried SameSite<\/code>, 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.<\/p>\n

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.<\/p>\n

What a missing HttpOnly actually costs<\/h2>\n

The three words are not equally replaceable.<\/p>\n

Without Secure<\/code>, 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.<\/p>\n

Without SameSite<\/code>, the browser applies its own default, which blocks the worst case unaided.<\/p>\n

Without HttpOnly<\/code>, 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.<\/p>\n

Which is why the ranking measured here runs the wrong way round. The word added least often is the one nothing else covers.<\/p>\n

\n

Questions and answers<\/h2>\n

Can every cookie be set with HttpOnly?<\/h3>\n

No. HttpOnly means no script can read the cookie, which rules out every cookie that exists for a script: the consent state a banner script has to read on the next page view, or the identifier an analytics tool writes and reads in the browser itself.<\/p>\n

A script also cannot set HttpOnly at all. Cookies created by a script through document.cookie<\/code> are also not set by a header, so they never appear in a Set-Cookie line and were not among those counted in the article; for them the question does not arise.<\/p>\n

For everything only the server needs, the opposite holds: session and login cookies are read by no script, and there is no reason to go without HttpOnly for them. A workable rule of thumb is therefore that whatever the server sets and no script on the page reads gets HttpOnly.<\/p>\n

Is a site with an HttpOnly session cookie safe from an injected script?<\/h3>\n

Only partly. HttpOnly stops a script from reading the value and carrying it off to use the session elsewhere later. It does not stop the script from acting inside the page: the browser automatically attaches the cookie to requests the script sends from there, so it can do anything the logged-in person is currently allowed to do, for as long as the page is open.<\/p>\n

HttpOnly therefore limits the damage rather than preventing it. Other measures work against the injected script itself, such as a Content Security Policy that defines where scripts may come from, and a sparing choice of third-party scripts.<\/p>\n

Why do cookies with SameSite=None practically always carry Secure as well?<\/h3>\n

Because Chrome and the other Chromium-based browsers have refused to accept a cookie with SameSite=None but without Secure since 2020. A cookie explicitly released for requests from other sites therefore has to be restricted to encrypted connections.<\/p>\n<\/div>\n

\n

Sources<\/h2>\n