Overview
Testing session management after login is a valuable bug bounty area, since session flaws can enable hijacking or fixation. This lesson covers session testing.
Learning objectives
- Identify session-management weaknesses to hunt for.
- Explain testing sessions safely and in-scope.
- Connect session flaws to hijacking/fixation.
Core concept
Session testing checks the session controls covered earlier (web-security cookies/sessions): are session identifiers unpredictable and regenerated at login (anti-fixation)? Are session cookies set with protective flags (HttpOnly, Secure, SameSite)? Do sessions expire (idle/absolute timeouts)? Does logout truly invalidate the session server-side? Weaknesses enable session hijacking (stealing/guessing a session) or fixation (planting a known session). In bug bounty, these are tested safely with the researcher's own test accounts, examining the application's session handling rather than attacking real users' sessions.
How it works
Using test accounts, the researcher inspects the session lifecycle: examining session identifiers for randomness and whether they change on login; reviewing session cookie flags; verifying sessions time out; and confirming logout invalidates the session server-side (replaying the old identifier after logout should fail). This is non-destructive observation using the researcher's own accounts. Each control maps to a known weakness: predictable IDs → hijacking; no regeneration → fixation; missing flags → theft; no expiry/broken logout → lingering sessions. Confirmed weaknesses are documented with evidence and fixes. Testing never targets real users' sessions.
Practical example
Testing an in-scope application with test accounts, the researcher finds the session cookie lacks the HttpOnly flag and that logout does not invalidate the session server-side (the old identifier still works afterward). Both are documented findings — the missing flag exposes the session to script-based theft, and broken logout leaves sessions usable — with fixes (HttpOnly; Secure; SameSite; server-side invalidation on logout). The researcher used only their own test accounts and non-destructive observation, identifying valid session findings responsibly.
Cybersecurity relevance
Session-management flaws can lead to hijacking or fixation — high-impact account-compromise findings — making session testing valuable in bug bounty. It validates the web-security session defenses (identifier strength/regeneration, cookie flags, expiration, logout invalidation) and is tested safely with test accounts, never against real users' sessions (per program rules). It complements login testing: securing login is insufficient if the session is poorly managed. Findings drive session hardening. Session testing is a standard, valuable part of authentication assessment in bug bounty.
Common mistakes
- Testing login but not the resulting session management.
- Not verifying server-side logout invalidation (only that the cookie is cleared).
- Overlooking session-ID regeneration (fixation) or cookie flags, or testing real users' sessions.
Key takeaways
- Session testing checks identifier strength/regeneration, cookie flags, expiration, and server-side logout invalidation — weaknesses enable hijacking or fixation.
- Test safely with the researcher's own test accounts via non-destructive observation, never real users' sessions (per program rules).
- It validates web-security session defenses and complements login testing; findings (missing flags, broken logout, fixation) drive session hardening.
Check your understanding
- What session-management controls should bug bounty testing verify?
- Why is checking server-side logout invalidation (not just cookie clearing) important?