Home / Knowledge hub / Session token
Knowledge hub
Session token
A random value the browser sends to show it belongs to a signed-in visit.
What it means
A session token, also called a session ID, is a value the server hands out at login. The browser sends it back on every later request, and the server looks it up to find who the visitor is. It is the key that stands in for the password after sign-in, and it is checked on every request.
A good one is long, random and meaningless. It does not contain a name, an email address, a role or any other detail an outsider could read or change. OWASP asks for a session identifier with at least 64 bits of entropy, produced by a cryptographically secure generator.
Why it matters
Whoever holds the token is, as far as the app is concerned, the user. No password or second factor is checked again. A stolen token passes through multi-factor authentication that was completed earlier, which is why session theft is attractive to attackers.
The cost is direct: data read, orders placed, settings changed, all under the real user's name. Because the token is the proof, protecting it must be treated with the same care as a password. Guessable, leaked or long-lived tokens are common causes of account takeover.
How it shows up
Tokens usually travel in a cookie with Secure, HttpOnly and SameSite set. They are sometimes sent in an Authorization header or, wrongly, in a URL where they land in logs, browser history and referrer headers. Exposure also happens through XSS, malware, shared proxies and log files that capture requests.
The mistakes: a token built from a counter, a timestamp or a user id; one that survives logout; one reissued without change after login; and one that never expires. Look at how tokens are made, where they are stored, and whether they can be replayed. See session fixation and token replay.
Questions people ask
Session token, answered
Is a session token the same as a JWT?
Not necessarily. A session token is a role: a value that identifies a visit. It can be an opaque random string looked up on the server, or a signed token like a JWT that carries its own data.
Either must be protected as carefully as a password.
Where should a session token not appear?
In a URL, in logs, in error messages, in analytics, or anywhere script can read it. URLs are copied, bookmarked, shared and sent to other sites as referrers.
Keep it in a protected cookie or a header, and strip it from logs.
What makes a session token secure?
It must be unpredictable, long enough, tied to a server-side record or signed, expired on time, and invalidated at logout and at password change. It should also be delivered with Secure, HttpOnly and SameSite.
Any one gap weakens the rest.
Can a token be stolen without breaking into the server?
Yes. Cross-site scripting, a malicious browser extension, malware on the device, a shared network without HTTPS, or a log that stores requests can each reveal it.
That is why short life and revocation matter.
How do we test a session token?
Collect many tokens and look for patterns, check the cookie attributes, test that logout and password change invalidate it, and try using one from another device.
Each result is evidence you can show.
Related
Terms that sit next to this one
Session management
How your app creates, tracks, renews and ends a signed-in visit.
Opaque token
A token with no readable content, looked up on the server to find who it is for.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Session fixation
An attacker sets your session id before login, then waits for it to work.
Token replay
Reusing a stolen or captured token to be accepted as its rightful owner.
What does the token let someone do?
We test how your session tokens are made, stored and retired, and whether a copied one still works from elsewhere. Findings carry the request and response that proved them. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.