Background: why sessions exist
HTTP is a stateless protocol — each request your browser sends to a server arrives with no memory of previous requests. Without any extra mechanism, the server cannot tell whether the request is from you or a stranger, because it treats every request as new. When you sign in to a web application, the server solves this by issuing a session token: a short value the browser stores and sends back with every subsequent request. The server reads the token, looks up the account it belongs to, and uses it to decide what you are allowed to do.
Modern web applications prove who you are on every request by presenting a session token that the server checks. NovaCart, like many real-world applications, uses a JSON Web Token (JWT) as that session credential. In this lesson you will inspect a real JWT, decode its claims in the browser, and exploit two long-standing JWT flaws.
This topic sits inside A07:2021 - Identification and Authentication Failures in the OWASP Top 10.
In this lesson you will:
- Locate the JWT issued at login and identify its three-segment structure.
- Decode the payload claims in the browser and observe what is signed but not encrypted.
- Forge a JWT header that disables signature verification using the
alg=noneflaw. - Contrast this with weak-secret signing, where the attacker recovers the HMAC secret by offline brute force.
- Compare local-storage and
HttpOnlycookie storage and learn which cookie attributes protect a session token.
Estimated time: fifteen to twenty minutes.
Prerequisite: register a normal user account in NovaCart and log in. You do not need administrative privileges to complete this lesson. You will only be experimenting with your own token.
Course position: this is the course's session-token reference point. Later OAuth, SAML, WebAuthn/passkey, and client-side storage lessons assume you understand that a JWT is signed, readable, and only trustworthy after server-side verification.
When you are ready, send the Continue signal.