Cookie Inspector & SameSite Auditor

List this page's cookies and audit a pasted Set-Cookie header for security flags

Reads the cookies readable from the current page via document.cookie, and audits any pasted Set-Cookie header for Secure, HttpOnly and SameSite flags — flagging missing Secure or improper SameSite that could enable CSRF or cross-site leakage. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why are HttpOnly cookies not in the page list?

HttpOnly cookies are deliberately hidden from JavaScript, so document.cookie cannot read them — that is the point of the flag. To see them, paste the server's Set-Cookie header into the auditor below.

Cookies carry sessions, preferences and tracking identifiers, and their security depends on three flags: Secure, HttpOnly and SameSite. This tool does two things: it lists the cookies the current page can read via document.cookie, and — because the most security-relevant cookies are HttpOnly and invisible to JavaScript — it also parses a pasted Set-Cookie header so you can audit those flags directly without opening network tools.

The two views: page cookies vs. header audit

Page cookie list: document.cookie returns only the non-HttpOnly cookies for the current origin as name=value pairs. Seeing which cookies are readable by JavaScript is itself a privacy signal — if a session token appears in this list, it is also readable by any injected script, which is exactly what HttpOnly is meant to prevent.

Header auditor: The security-critical cookies — session IDs, auth tokens, CSRF tokens — are typically HttpOnly, so they never appear in the page list. To audit them, copy the raw Set-Cookie line from your browser’s network tab or a curl response and paste it here. The parser reads every attribute.

What the auditor checks

The parser splits the header on ; and reads: Secure, HttpOnly, SameSite, Domain, Path, Max-Age and Expires. It then applies three validation rules:

  • SameSite=None requires Secure, or modern browsers reject the cookie outright — your session will break.
  • A cookie with a session/auth name (session, sid, token, auth, jwt) should carry both Secure and HttpOnly. Missing either is flagged.
  • Missing SameSite defaults to Lax in modern browsers but is worth setting explicitly so behaviour does not depend on the browser version.

Worked example

Set-Cookie: sid=abc123; Path=/; SameSite=None

This raises a warning: SameSite=None is set without Secure, so the browser drops the cookie and the session breaks. The correct header is:

Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

That clears all warnings: the session ID is hidden from scripts, only sent over HTTPS, and restricted from being included on cross-site requests automatically.

MistakeRisk
Session token readable by JS (no HttpOnly)Stolen by XSS
Cookie sent over HTTP (no Secure)Intercepted on the network
SameSite=None without SecureRejected by all modern browsers
No SameSite attributeBrowser-dependent behaviour; CSRF exposure in older browsers

Everything runs locally — the auditor inspects only what you paste and makes no network requests.