Skip to content
apikey.tools
JWTTokens

API Session Token & Cookie Inspector

Decode a session value and audit the cookie attributes that decide whether it is stealable.

JWTRuns in this tabInput not transmitted

Input

Paste the whole Set-Cookie value to audit its attributes too.

Output

computing

Paste a whole Set-Cookie value and this tells you two things: what the session value actually is, and whether the attributes around it make it stealable.

The attribute audit

Three flags do most of the work, and missing any of them is a real vulnerability rather than a style issue.

Secure — the cookie is sent only over HTTPS. Without it, any plain-HTTP request to your domain leaks the session to anyone on the network. A single unencrypted request to http://yoursite.com — a mistyped link, an old bookmark, an HTTP redirect — is enough.

HttpOnly — JavaScript cannot read the cookie. Without it, any XSS anywhere on your origin exfiltrates every user's session in one line. This is the flag that turns a contained XSS into a full account takeover.

SameSite — controls whether the cookie is sent on cross-site requests. Lax is the modern browser default and blocks most CSRF. Strict is stronger but breaks inbound links from other sites. None sends the cookie everywhere and requires Secure; use it only when you genuinely need cross-site auth.

Two more matter:

Domain — omitting it produces a host-only cookie, which is what you want. Setting Domain=.example.com shares the session with every subdomain, including one a marketing team spins up on a third-party platform.

Path — rarely useful for isolation, since same-origin JavaScript can read across paths anyway.

What the value is

The inspector recognises three shapes:

  • JWT — decoded and shown. This means your session state is in the cookie, so you cannot revoke it before expiry without a denylist.
  • Signed value — a payload and a signature, as Rails, Django and cookie-session produce. The payload is readable by the user, so nothing secret belongs in it.
  • Opaque — a random identifier that means nothing without your server's session store. This is the safest design, because revocation is a single delete.

Entropy

A session identifier is a bearer credential. If it is guessable, an attacker becomes a logged-in user. 128 bits is the target, and anything under 96 is a finding — the readout measures the actual search space of the value you pasted.

Sequential or predictable session IDs still appear in older systems and in hand-rolled session handling. The entropy calculator gives a fuller structural analysis.

Frequently asked questions

Is SameSite=Lax enough to stop CSRF?

It blocks cross-site POST requests, which covers the common case. It does not cover top-level GET navigations, so any state-changing GET endpoint remains exposed — those should not exist. For sensitive actions, keep CSRF tokens as well.

Should I set an expiry on session cookies?

A session cookie with no Expires or Max-Age is deleted when the browser closes, which is the safer default for shared machines. Persistent sessions need an absolute maximum lifetime enforced server-side regardless of the cookie.

More tokens tools

Decode and dissect bearer credentials