Module 9 · Session Tokens — Where Auth Bugs Live After Login 🔒

A session token is a tiny string that represents “I am logged in as user X.” The security of the entire application reduces to: who holds these strings, how they’re generated, and under what conditions they become invalid. Most web breaches boil down to a token handling failure somewhere in that chain.

Why this happens

Session tokens are distributed trust. The server issued the token. For the rest of the session, the server trusts whoever presents it. If the attacker gets the token — by theft, prediction, or logic bug — they become the user. No password needed, no MFA triggered.

Developers focus intense attention on authentication (login flow, MFA, password complexity) and relatively less on session handling. The attacker flips this: they often don’t touch the login flow. They target session tokens that are already issued to legitimate users.

How it goes wrong

1. Token predictability

Old apps used sequential IDs or time-based tokens. Modern apps mostly use cryptographically random tokens. The handful that don’t (often custom schemes in smaller apps) yield to brute force or prediction.

2. Token transmission in URL

Session ID in URL (?PHPSESSID=abc) leaks via referrer, logs, shared bookmarks. Best practice for 20+ years; still appears in legacy apps.