Cookie Security Checker: Secure, HttpOnly, SameSite

Cookie security flags explained

A cookie's security comes from the attributes on its Set-Cookie response header. A well-configured session cookie looks like this:

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax

HttpOnly cookie

HttpOnly hides the cookie from JavaScript. document.cookie will not include it, but the browser still sends it with every request. That makes it the main defence against session theft through cross-site scripting: even if an attacker gets a script onto your page, they cannot read the session cookie and replay it elsewhere. Every session and "remember me" cookie should be HttpOnly. The exception is a CSRF token cookie designed to be read by your own JavaScript.

Cookie Secure flag

Secure means the browser only sends the cookie over HTTPS. Without it, a single request to http:// (an old link, a typed address before your redirect) sends the cookie in clear text to anyone on the network. Pair it with HSTS so the browser never makes that HTTP request in the first place.

SameSite: Lax vs Strict vs None

Strict: never sent on requests started by another site, including when a user clicks a link to you. Strongest, but users arriving from a link look logged out until they navigate.
Lax: sent on top-level navigations (clicking a link) but not on cross-site POSTs, iframes, images or fetches. The right default for session cookies, and a strong layer against CSRF.
None: sent everywhere, including cross-site. Only for cookies that must work in third-party contexts, and only together with Secure; browsers reject SameSite=None without it.

If you leave SameSite out, Chromium-based browsers treat the cookie as Lax, but Firefox and Safari do not apply that default. Set it explicitly.

Cookie prefixes: Host- and Secure-

A cookie named __Host-… is only accepted if it is Secure, has Path=/ and no Domain. That locks it to one exact host, so a compromised subdomain cannot overwrite your session cookie (cookie tossing). __Secure-… only requires Secure. Both are enforced by the browser, which makes them stronger than the attributes alone.

Domain and lifetime

Setting Domain=example.com shares a cookie with every subdomain. Leave Domain off unless you need that, especially for session cookies. Keep session cookies short-lived: a session cookie with a 30-day Max-Age gives a stolen copy 30 days of use.

Laravel cookie settings

Laravel's session cookie (named from APP_NAME, for example myapp_session) takes its flags from config/session.php:

// .env
SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax

// config/session.php
'secure' => env('SESSION_SECURE_COOKIE'),
'http_only' => true,
'same_site' => env('SESSION_SAME_SITE', 'lax'),
'domain' => env('SESSION_DOMAIN'), // leave null unless subdomains share the session

The XSRF-TOKEN cookie follows the same secure and same_site settings and is deliberately readable by JavaScript. The remember_web_… cookie is long-lived by design. More in our guides to Laravel session security and fixing insecure session config.

FAQ

What is an HttpOnly cookie?

A cookie with the HttpOnly attribute cannot be read by JavaScript (document.cookie). The browser still sends it with requests, so session cookies keep working, but an XSS bug cannot steal them.

What does the Secure flag on a cookie do?

A Secure cookie is only sent over HTTPS, never over plain HTTP, so it cannot be read by someone intercepting unencrypted traffic. Browsers also refuse to let an HTTP page set a Secure cookie.

Should I use SameSite Lax or Strict?

Lax for session cookies on most sites: it blocks cookies on cross-site POSTs and background requests but keeps users logged in when they follow a link to you. Strict also drops the cookie on that first top-level navigation from another site, which feels like being logged out.

When do I need SameSite=None?

Only when your cookie must be sent in a third-party context, such as an embedded widget or a cross-site iframe. It must be combined with Secure, or browsers reject the cookie.

Why is Laravel's XSRF-TOKEN cookie not HttpOnly?

Because JavaScript has to read it. Axios copies XSRF-TOKEN into the X-XSRF-TOKEN request header, which Laravel checks against the session. The value is useless to another site, so not being HttpOnly is by design.

Does this tool store my cookies?

No. We read the Set-Cookie headers from one request (following up to five redirects), grade the attributes, and never store or display cookie values.

Cookie Security Checker