Applied · Module 2
Identity and access control
Authentication answers who you are.
Previously
Threat modelling as design
Security improves fastest when I can answer one question clearly.
This module
Identity and access control
Authentication answers who you are.
Next
Web security in practice
Most breaches start with what is exposed, not with exotic zero days.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A session is a bridge in a stateless world.
What you will be able to do
- 1 Explain authentication, authorisation, and sessions without mixing them up
- 2 Explain how cookies and tokens can fail in real web flows
- 3 Name two controls that reduce session replay risk
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Shadow access. Access granted through forgotten paths and legacy endpoints becomes the breach route.
- Policy drift. If policy lives in three places, it will disagree. Centralise and test it.
Main idea at a glance
Session flow at a glance
Login creates a session token that rides with each request.
Session trust lifecycle
`flowchart LR
Login["User\nlogin"] --> Issue["Issue session\ntoken"]
Issue --> Cookie["Store secure\ncookie"]
Cookie --> Request["Authenticated\nrequest"]
Request --> Verify["Verify token\n& auth"]
Verify --> Allow["Allowed\naction"]
Verify --> Deny["Denied &\naudit log"]
Allow --> Rotate["Rotate on\nprivilege change"]
Rotate --> Expire["Expire on\nlogout"]
`Session trust lifecycle
A session is a bridge in a stateless world. Cookies or tokens are just carriers. Their safety depends on creation, storage, expiry, rotation and server side checks.
In simple terms, a session is the site remembering you between clicks. Without it, every request looks like a stranger. With it, every request is trusted as "you", which is powerful and therefore risky.
In the real world, what I see is not magic crypto. I see teams choosing between cookies and tokens, setting expiries, deciding how logout works, and then finding out that one missing authorisation check exposed data. I also see incidents where a stolen session gets reused from a different device, and nobody notices because there is no monitoring on session anomalies.
Common failures include predictable IDs, missing privilege escalation, and replaying stolen token. Another failure is confusing authentication with authorisation. Users log in correctly, but the app forgets to check what they are allowed to do.
How to do it well. Use secure and HttpOnly cookies where possible, set short lifetimes for high risk sessions, rotate tokens on sensitive events, and invalidate server side on logout. Also treat authorisation as a rule that must be enforced on every request, not just in the UI. The trade off is user convenience. Short sessions can annoy users, so you need to decide where you accept friction and where you compensate with better UX.
Before you use the session flow tool, focus on what is stored where. The browser will happily send cookies back to the server. The question is whether the server should believe them, and under what conditions.
After you use it, check you can explain where the trust comes from. If your model is "the cookie proves it is me forever," you are missing expiry, rotation, and invalidation.
Before you use the hijack demo, this is not teaching you to attack anyone. It is showing why session identifiers are sensitive. If someone gets one, they often do not need your password.
After you use it, focus on the controls that break the replay. Short lifetimes, rotation, binding sessions to device signals, and server side invalidation all reduce the window. A common mistake is assuming HTTPS alone prevents session theft. HTTPS protects transport, not your entire browser environment.
Real-world impact of getting cookie security wrong
In 2018, British Airways experienced a data breach affecting 500,000 customers. Attackers injected malicious code into the airline's website that stole payment card details. The attack worked because cookies were not properly secured. The ICO fined British Airways £20 million for the breach. The direct cost was significant, but the reputational damage was worse. Customers lost trust, and the incident raised questions about the airline's ability to protect sensitive payment information.
Why cookie security matters
Cookies carry session identifiers and authentication tokens. If they are not configured correctly, attackers can steal sessions, hijack accounts, and access sensitive data. Missing the Secure flag means cookies can be sent over unencrypted HTTP. Missing HttpOnly means JavaScript can access cookies, making XSS attacks more dangerous. Missing SameSite means cookies can be sent in cross-site requests, enabling CSRF attacks.
Practice with the Cookie Checker
Use the cookie checker tool to analyse real cookie configurations. See what secure cookies look like versus insecure ones. Understand how missing flags create vulnerabilities. This hands-on practice builds the skills you need to spot cookie security issues in real applications.
Mental model
Policy and enforcement
Access control works when policy is clear and enforcement is consistent at every entry point.
-
1
Identity
-
2
Policy
-
3
Enforcement
-
4
Audit logs
Assumptions to keep in mind
- Least privilege is maintained. Least privilege is not a one-time setting. It needs review, ownership, and removal of old grants.
- Admin is separated. Admin paths are a different trust model. Treat them as high-risk by default.
Failure modes to notice
- Shadow access. Access granted through forgotten paths and legacy endpoints becomes the breach route.
- Policy drift. If policy lives in three places, it will disagree. Centralise and test it.
Key terms
- privilege escalation
- checks that stop users gaining extra rights
- token
- credentials stored in cookies or headers
Check yourself
Quick check. Identity and sessions
0 of 7 opened
How do authentication and authorisation differ
Authentication proves identity. Authorisation decides what that identity may do.
Why are secure and HttpOnly flags important
They reduce theft by limiting script access and forcing transport security.
What breaks when you skip authorisation
Users can access data or actions they should not, even if they logged in correctly.
Scenario. A session token is stolen and replayed from another device. What controls reduce the damage window
Short lifetimes, rotation on sensitive events, server-side invalidation, and monitoring for anomalies (new device, new country, unusual timing).
How does session rotation help
It invalidates old tokens so stolen tokens are less useful.
Name one sign of privilege escalation
A normal user invoking an admin-only action without being stopped.
What should happen on logout
Server side invalidation of the token or session so reuse fails.
Artefact and reflection
Artefact
A short checklist for session safety and cookie flags
Reflection
Where in your work would explain authentication, authorisation, and sessions without mixing them up change a decision, and what evidence would make you trust that change?
Optional practice
Step through login, token or cookie creation and a couple of requests to see how state moves with the user.
Also in this module
See session hijacking in action
Replay a stolen session identifier and practice the controls that shut it down.
Cookie Checker & Analyser
Analyse cookie attributes and identify security issues. Practise spotting missing Secure, HttpOnly, and SameSite flags.