Session Security Lab
Most account takeovers are not a broken password — they are a broken session. Review a queue of session-management configs and call each one: hardened, or name the defect — a cookie missing HttpOnly or Secure, a SameSite that re-opens CSRF, a session ID that never rotates (fixation), a missing idle or absolute timeout, a logout that never reaches the server, or a __Host- prefix problem — then pick the fix. You are scored on catch rate against false positives, because a cross-site SameSite=None and a legitimate parent-domain SSO cookie are correct, not findings. Clear the queue clean.
The real job. More noise, a tighter clock.
Session review queue
Call each session config Secure, or name the finding — then pick the correct fix.
#1 · Northwind customer portal
__Host-sid
context: First-party web app, no cross-site embedding
#2 · Helpdesk ticketing
sid
context: First-party web app
#3 · Marketing CMS
sid
context: First-party web app reachable on http:// and https://
#4 · Expense dashboard
sid
context: First-party web app — no cross-site embedding or SSO
#5 · Member community
sid
context: First-party web app; the ID is issued to anonymous visitors
#6 · HR self-service
sid
context: First-party web app, stateless tokens
#7 · Admin console
sid
context: First-party high-privilege console
#8 · Partner SSO (embedded)
sid
context: Legitimately embedded cross-site in a partner iframe / SSO flow
#9 · Trading desk
sid
context: First-party web app; an idle timeout is present
#10 · Billing portal
__Host-sid ⚠ prefix + Domain
context: First-party web app; cookie carries the __Host- prefix
#11 · Mobile API gateway
__Host-at
context: First-party; stateless tokens with revocation
#12 · Reporting API
sid
context: First-party SPA + API on the same site — no cross-site calls
#13 · Analytics SPA
sid
context: HttpOnly deliberately off so the SPA can read the session token in JS
#14 · Finance app (step-up)
__Host-sid
context: First-party; ID rotates at login but NOT at privilege elevation
Catch rate vs. false positives
Call each config, then grade. So far 0/14 called, 0/11 fully resolved, 0 false positive(s).
How it is scored
Catch rate = vulnerable configs given the exact finding and the right fix.
A false positive (flagging a hardened config) takes an extra hygiene bite — and naming the right finding with the wrong fix is a partial miss.
Harder tiers add subtler configs and traps: a correct cross-site SameSite=None, a legitimate parent-domain SSO cookie, and a valid stateless-token logout.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based session-security lab: review a queue of session-management configs and call each one Secure or name its specific defect — then pick the correct fix.
- Findings seeded across the queue: missing HttpOnly, missing Secure, weak SameSite (CSRF), session fixation (no ID rotation), no idle timeout, no absolute timeout, logout that never invalidates server-side, and __Host- prefix problems.
- Each decision pairs with a remediation, so you practise the fix — rotate the ID, set SameSite=Lax, enforce an idle timeout, deny-list the token on logout — not just the diagnosis.
- You are graded on catch rate weighed against false positives: a correct cross-site SameSite=None, a legitimate parent-domain SSO cookie, and a valid stateless-token logout are traps you must NOT flag.
- Runs entirely in your browser — authored configs, no upload, no account — and after grading every config explains why its finding and fix are right.
Frequently asked questions
What is the Session Security Lab?
A free, in-browser exercise where you review session-management configurations — the HttpOnly, Secure and SameSite cookie attributes, the __Host- prefix and cookie Domain/Path scope, idle and absolute timeouts, whether the session ID rotates on login and privilege change, and what logout actually does on the server — and for each one you decide Secure or name the specific weakness, then choose the correct remediation. You are scored on how many real problems you catch and fix versus how many hardened configs you wrongly flag.
What session weaknesses does it cover?
Missing HttpOnly (an XSS can read the cookie), missing Secure (the cookie leaks over plaintext HTTP), weak SameSite that re-opens CSRF on a first-party session, session fixation where the ID is not regenerated at login or privilege elevation, a missing idle (inactivity) timeout, a missing absolute lifetime cap, logout that only clears the client cookie while the server session or stateless token stays valid, and __Host- prefix problems — both a sensitive cookie that should be host-locked and a __Host- cookie invalidated by a Domain attribute.
How is it graded?
Each config has one correct finding and one correct fix. Your catch rate is the share of vulnerable configs you both identify and remediate correctly. Naming the right finding but the wrong fix is a partial miss, and a false positive — flagging a hardened config as vulnerable — carries an extra hygiene penalty, because an alert queue engineers cannot trust is as useless as one that misses defects. A perfect run calls every config exactly right, secure ones included.
Who is it for?
Application-security and IAM engineers, backend and platform developers who own authentication, and anyone prepping for a security interview who wants to feel why SameSite=None is fine for a genuinely cross-site cookie but a CSRF hole on a first-party one, why a parent-domain SSO cookie legitimately cannot use __Host-, and why a logout that never reaches the server leaves a stolen token working. No account, no install, nothing uploaded.