Secure cookie attributes: what each stops
Three attributes protect a cookie. Secure keeps it to HTTPS connections, HttpOnly hides it from the page's scripts, and SameSite limits when it is sent on requests coming from another site. A session or login cookie needs all three; a cookie that remembers the visitor's language does not.
They are part of what a website security audit checks, along with headers and the certificate.
What each attribute prevents
A session cookie is what tells your site a visitor is logged in. Whoever gets hold of it can pose as that visitor. Each attribute closes a different path to it.
- Secure: the browser only sends the cookie over an encrypted connection (HTTPS). Without it, the cookie can travel unencrypted, for example during a redirect from an "http" address.
- HttpOnly: the cookie stays invisible to the page's JavaScript. Without it, a script injected into the page can read it and send it elsewhere.
- SameSite: the browser holds the cookie back, fully or in some cases, when the request starts on another site. Without it, another site can trigger an action on yours on behalf of a logged-in visitor. Its values are Strict, Lax and None.
When SameSite is missing, behavior depends on the browser: recent browsers apply Lax, older ones apply no restriction. Secure and HttpOnly date back to RFC 6265; SameSite is defined in the revision of the cookie standard now at the IETF.
Not every cookie needs them
The recommendations of France's national cybersecurity agency (ANSSI) are specific here (in French). A session cookie should carry HttpOnly, and SameSite set to anything but None. Once a site is served only over HTTPS, its cookies should carry Secure.
A cookie that remembers the language or the consent choice gives access to nothing. If the page's scripts can read it, that's not a defect: some need to. That's why a raw list of cookies missing an attribute can't tell you, on its own, whether a site has a problem.
What we find on the sites we audit
40%set at least one session, login or personal-data cookie missing one of the three attributes
This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.
What the audit looks at, cookie by cookie
The audit records the cookies your site sets while its pages are visited, before any choice in the consent banner. For each one, it notes the domain that sets it and whether Secure, HttpOnly and SameSite are there.
Then comes a judgment: among the cookies missing an attribute, does any carry a session, a login or personal data? If so, the finding stands, and the report names the cookie and what it lacks. If they are only preference cookies, there is nothing to fix.
The finding takes a fixed number of points off the pillar score, however many cookies are involved.
What is a quick fix, and what takes a project
A cookie can come from your own code, a CMS plugin or a service the page calls. The fix goes through whoever sets it. For a cookie from your own code, adding the attributes is a setting. For a plugin, it's often an option, sometimes a request to its developer.
Two cases take more work. If your application reads its own session cookie from the page, HttpOnly blocks that: the way it identifies users has to change. And SameSite set to Strict holds the cookie back when a visitor arrives through a link from another site, such as an email, so depending on the flow the login seems lost. The choice between Strict and Lax is made cookie by cookie, depending on how visitors reach the site.
Secure only helps if the whole site is served over HTTPS. That is the job of the HSTS header, one of the HTTP security headers.
What this check doesn't tell you
We see the cookies set on the public pages we visit. Cookies from a customer area or an admin page, set after login, are out of reach.
A well-protected cookie says nothing about how your server handles the session: how long it lasts, how it is revoked, what it holds. None of that is visible from outside.
Read next
HTTP security headers: which ones matter
HSTS, CSP, X-Frame-Options: what each HTTP security header prevents, which ones come first, and what the audit records on your website.
Read the guide →HSTS: what it protects, and what can break
HSTS makes browsers use HTTPS from the very first request. What max-age, includeSubDomains and preload do, what breaks, and what the audit reads.
Read the guide →