1001Ferramentas
🍪Dev

Cookie Flags Analyzer

Inspect Set-Cookie header and flag missing Secure, HttpOnly, SameSite — with suggested fixes.

Checking the security flags on a Set-Cookie

Paste the header and the page checks the five decisions that set a cookie's exposure: Secure, HttpOnly, SameSite, Path and lifetime. Each comes with the concrete effect of being present or absent, rather than a bare right-or-wrong mark — because a session cookie and a preference cookie do not call for the same thing.

The check runs against the real attributes, and that distinction matters more than it seems. Searching for the word secure across the whole header reports the flag present on a cookie merely named secure_token, or whose value contains the word. That is the kind of false positive that gets someone to tick off as fixed a cookie still travelling in the clear.

The page also checks the name prefixes, a little-known contract: a cookie starting with __Secure- is only accepted by the browser if it carries Secure, and one starting with __Host- requires Secure, Path set to slash and no Domain. When the contract is not met, the browser discards the whole Set-Cookie — with no console error, which makes the failure hard to diagnose.

Frequently asked questions

Is SameSite=None always bad?
No, it is necessary in legitimate third-party scenarios — an embedded widget, federated authentication, payment in an iframe. What is not allowed is None without Secure: browsers have rejected that combination since 2020. When the cookie need not cross sites, Lax is the sensible default and Strict the safest.
Does HttpOnly protect against session theft?
It closes the easiest route, which is reading the cookie from script. It does not protect against everything: with script execution on the page, an attacker can act as the user without ever seeing the cookie, because the browser sends it unprompted. HttpOnly is a layer, not a solution.
What does the __Host- prefix guarantee in practice?
That the cookie was set by the host itself, applies to the whole site and cannot have come from a subdomain. That closes a real class of attack — a compromised subdomain writing a cookie the main domain accepts. For session and CSRF-protection cookies it is the strongest option available.

Related Tools