Insecure Cookie Flag¶

Scope and impact¶

Authentication and session cookies need attributes appropriate to their purpose. Missing Secure can expose a cookie on cleartext requests. Missing HttpOnly allows page JavaScript to read it. These are separate risks; a non-sensitive preference cookie may intentionally be readable by JavaScript.

Matched response-header example¶

The value below is a fixture placeholder, not a production session identifier. Real sessions need unpredictable server-issued identifiers or framework-protected tickets, expiry and server-side authorization.

Unsafe for an authentication session:

Set-Cookie: session=fixture-only; Path=/

Safer for a same-site session flow:

Set-Cookie: session=fixture-only; Path=/; Secure; HttpOnly; SameSite=Lax

Secure restricts transmission to secure connections, subject to browser localhost exceptions. HttpOnly prevents ordinary script access to the cookie; it does not prevent an XSS payload from making authenticated requests. SameSite=Lax restricts some cross-site sending, with exceptions such as qualifying top-level navigations. Review the browser's Set-Cookie rules.

Omit Domain unless subdomain sharing is required. A __Host- name adds browser-enforced constraints when combined with Secure, Path=/ and no Domain. Choose Strict, Lax or None for the actual login/embed flow; None requires Secure. Do not weaken policy merely to hide a broken integration.

Regression check¶

On a disposable HTTPS origin, inspect the received cookie, verify it is absent from document.cookie, and test same-site navigation, logout and the supported external identity-provider flow. Confirm it is not sent over HTTP. Keep CSRF defenses on state-changing requests and use safe HTTP method semantics. See CSRF and session fixation.