Skip to lesson
Exit
Application Security & Secure Code Review1 / 3

2 min lesson

Sessions, tokens and JWT misuse

Think through this situation: "In review you see db.get(Document, id=req.params.id) returned directly to an authenticated user. What's the vulnerability and the fix?" Give the practical answer in plain words.

Step 1 of 3

Sessions, tokens and JWT misusewhere token handling goes wrong

  • `alg: none` and algorithm confusion. A verifier that trusts the token's own alg header can be tricked into skipping signature checks or into verifying an RS256 token with the public key used as an HMAC secret. Pin the expected algorithm server-side.
  • No expiry or no revocation. Long-lived JWTs can't be recalled once issued. Keep access tokens short and pair them with a server-checked refresh or session, so a stolen token dies quickly.
  • Tokens in the wrong place. A JWT in localStorage is reachable by any XSS. Prefer HttpOnly, Secure, SameSite cookies for browser sessions; keep secrets out of URLs and logs.
  • Trusting unsigned claims. Authorization decisions must read server-verified claims, never fields the client can edit. is_admin: true in a tampered token is the classic.
Watch out - multi-tenant isolation

Never trust the client for tenant scoping. The tenant ID must come from the authenticated session, not a request parameter or header the caller sets. The cleanest enforcement pushes tenant scoping into the data layer (row-level security or a query that always filters by tenant_id = session.tenant) so a single forgotten check can't cross-tenant-leak. For Cursor, where customer code and context are the crown jewels, tenant isolation is the breach you most need to make structurally impossible.