Cookies missing Secure / HttpOnly / SameSite flags
Three attributes determine who can read, steal, or replay a cookie. Without them, a session cookie — often the only thing separating an anonymous visitor from a logged-in account — becomes vulnerable.
Secure
Without this attribute, the cookie can be sent over an unencrypted HTTP connection if a request ever goes out over HTTP by accident (a malformed link, an old resource) — exposing its value in plain text on the network.
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=LaxHttpOnly
Without this attribute, the cookie is accessible via document.cookie in JavaScript. If an XSS vulnerability exists anywhere on the site (even in a third-party library), an injected script can read and exfiltrate the session cookie directly.
SameSite
Without this attribute, the browser sends the cookie even on requests triggered from another site — the classic setup for a CSRF attack (a malicious site makes your logged-in user unknowingly act on your site).
Strict— the safest, but breaks navigation if an external link leads to a page that needs the cookie.Lax— a good default compromise, protects against most CSRF attacks while keeping normal navigation working.
Where to fix it
These attributes get set wherever the cookie is created — your auth framework (NextAuth, Supabase Auth...), or your own code if you handle sessions by hand. Check your framework's session configuration rather than trying to intercept and rewrite cookies after the fact.
Check whether your site is affected by this vulnerability.
Scan my app