Skip to content

Security

Secure, HttpOnly and SameSite cookie flags explained

`HttpOnly` is what stops any script on the page from reading a session cookie — without it, one injected script is a full account takeover. `Secure` stops it being sent over plain HTTP, and `SameSite` is the main defence against cross-site request forgery.

What 13x checks

This is rule security.cookie-flags in the public registry: Cookies carry the right flags. It runs on every audit, against the pages we actually fetched, and its result is derived from the response rather than estimated.

Surface
Security
Score weight
7 of the readiness score
Scope
Runs on every audited page
Applies
Only where the market or the page shape makes it relevant

Registry version 2026-07-30. Every rule is published, and the audit is deterministic — the same page produces the same finding every time.

The fix

The same text the audit hands you when this check fails on your own site.

Cookies missing flags: .

Set all three on anything session-related:

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

- HttpOnly — the important one. Without it, any script on the page can read the cookie, so one injected script is a full account takeover. A cookie your own JavaScript legitimately needs to read cannot have this, which is itself a reason to keep session tokens out of readable cookies. - Secure — never sent over plain HTTP. - SameSite=Lax — the main CSRF defence, and a sensible default. Strict breaks the case where someone follows a link into your app and expects to still be logged in. None requires Secure and should only be used for genuine cross-site embedding.

Framework-specific versions

Where the change differs enough to be worth writing out separately.

Does your site have this problem?

13x checks this and 112 others against your live URL in about 30 seconds. No account, and every finding comes with the fix for your framework.

No signup. Results in 30 seconds.

More security checks