Cookie Security Flags: Reading Set-Cookie Headers Properly

Cookies are small pieces of data that a site asks a browser to store and send back on later visits, and they are how the web remembers logins, preferences and shopping baskets. Because cookies often carry session identifiers, which are effectively temporary passwords, their security settings matter a great deal. A cookie sent over an insecure connection, read by a script, or attached to a request from another site can be abused in ways that are invisible to the visitor. The Cookie Security Checker checks pasted Set-Cookie headers for security flags, reporting which protections are present and which are missing. It works on pasted text, so it cannot observe live cookies or prove how a site behaves; it can only read the headers you supply.

How it works

Three flags do most of the protective work. The Secure flag tells the browser to send the cookie only over encrypted HTTPS connections, so it is never exposed on plain HTTP. The HttpOnly flag tells the browser not to expose the cookie to JavaScript, which blocks a common way that cross-site scripting attacks steal session cookies. The SameSite attribute controls whether the cookie is sent with requests from other sites, with values such as Strict, which blocks cross-site sending entirely, Lax, which allows it for top-level navigation such as following a link, and None, which allows it but requires the Secure flag as well. Each flag blocks a different abuse, so a cookie needs the right combination for its purpose, not merely one flag chosen at random.

Where it goes wrong

The Expires and Max-Age attributes govern lifetime, and they have security implications too. A session cookie that lasts for years extends the window in which a stolen cookie remains useful, while a short-lived cookie limits that window but may annoy users with frequent logins. The Path and Domain attributes govern scope: a cookie scoped to a whole domain is sent to every subdomain, which is sometimes necessary and sometimes an unnecessary widening. The Partitioned attribute, used with Secure, relates to cross-site contexts in newer browsers. None of these attributes is a substitute for the three main flags; they shape where and how long a cookie is sent, while the flags shape whether it can be stolen or misused along the way.

Worked example

Worked example with sample values. Suppose you paste 3 sample Set-Cookie headers. The first reads session=abc123; Secure; HttpOnly; SameSite=Lax, the second reads prefs=dark; Secure; SameSite=Strict, and the third reads tracking=xyz; SameSite=None without a Secure flag. Counting the flags gives a clear picture: Secure appears in 2 out of 3 headers, and 2 divided by 3 equals approximately 0.67, or about 67 percent. HttpOnly appears in 1 out of 3, which is about 33 percent. SameSite appears in 3 out of 3, which is 100 percent. The third header is the problem case: SameSite=None without Secure is an invalid combination in modern browsers, which may reject the cookie entirely, so the count alone does not capture the severity. The sample headers here are illustrative, with sample values rather than real session identifiers.

Mistakes to avoid

Common mistakes follow from copying cookie settings between contexts where they do not belong. A cookie that needs cross-site sending is given SameSite=Strict and stops working, so a developer removes all flags instead of choosing Lax or None with Secure. A development cookie without Secure is copied to production, where it travels over HTTPS anyway but is not protected if any part of the site is ever served over HTTP. A session cookie is given a lifetime of years for convenience, widening the theft window. Each of these is a trade-off made without noticing it, and a header check makes the trade-off visible by listing exactly which flags each cookie carries.

Putting it into practice

Use the checker when reviewing a site's cookies, especially session and authentication cookies, which deserve the strictest settings. Paste the headers, read each flag, and compare the combination against the cookie's purpose: a session cookie normally wants Secure, HttpOnly and a restrictive SameSite value, while a preference cookie may need less. Remember that the checker reads pasted headers, so confirm live behaviour separately, and remember that flags are one layer: they do not replace secure session handling, proper authentication, or protection against scripting attacks. A well-flagged cookie is harder to steal and harder to misuse, which is a meaningful gain for a few words of configuration.

Related tools and reading: the Password Generator and the JSON Studio cover neighbouring checks that pair naturally with this one, and the guide at [/blog/http-security-headers-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

  • Session cookies carry Secure, HttpOnly and a SameSite value
  • SameSite=None always paired with Secure
  • Cookie lifetimes kept as short as the purpose allows
  • Domain and Path scope kept as narrow as possible
  • Live cookies confirmed separately after configuration changes

In short: Cookies carry state between a browser and a site. The checker examines pasted Set-Cookie headers for security flags. Secure, HttpOnly and SameSite each block a different abuse. A missing flag is a gap, not proof of an active attack.

One habit ties all of this together: re-check after every change. A result from the Cookie Security Checker is only as current as the text it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.