Cookie Security Checker

A secure cookie has several attributes: the Secure flag (only sent over HTTPS, never HTTP), the HttpOnly flag (not accessible via JavaScript, preventing XSS theft), a SameSite attribute (Strict or Lax, preventing cross-site request forgery), and an appropriate Expires or Max-Age (not indefinitely persistent for sensitive cookies). For session cookies, the Path and Domain attributes should be as restrictive as possible, and the cookie name should ideally use the __Host- or __Secure- prefix for additional security guarantees.

The HttpOnly flag prevents client-side JavaScript from accessing the cookie via document.cookie. This protects session cookies and other sensitive tokens from being stolen by XSS attacks — even if an attacker successfully injects a script into your page, they cannot read HttpOnly cookies. The flag does not prevent the cookie from being sent with HTTP requests; it only restricts JavaScript access. All session and authentication cookies should have HttpOnly set.

SameSite controls whether a cookie is sent with cross-site requests. SameSite=Strict means the cookie is only sent with same-site requests (not from external links or cross-origin fetches). SameSite=Lax (the modern browser default) sends the cookie with same-site requests and top-level navigations (e.g. clicking a link) but not with cross-origin subresource requests. SameSite=None requires the Secure flag and sends the cookie with all requests, including cross-site ones (needed for embedded third-party content).

Cookie name prefixes add security guarantees enforced by browsers. __Secure- requires that the cookie be set with the Secure flag over HTTPS; browsers reject it otherwise. __Host- is stricter: it additionally requires that no Domain attribute is set (so the cookie is bound to the exact host, not subdomains) and that the Path attribute is /. These prefixes prevent cookie injection attacks where a subdomain or HTTP page sets a cookie that appears to come from the secure parent domain.