Direct answer
Session security testing checks how authenticated state is created, carried, changed, and invalidated. Use a test account to verify cookie protections and whether protected requests remain usable after logout, expiry, or a relevant permission change.
Map the authentication state
Identify whether the application uses server sessions, bearer tokens, refresh tokens, or a combination. Record where each value is stored and which requests use it. A cookie name or token shape alone does not explain the revocation model.
- Follow login, refresh, logout, and account-switching journeys.
- Keep raw tokens out of shared screenshots and reports.
- Distinguish application state from identity-provider state.
Review browser cookie protections
For cookie-based sessions, inspect Secure, HttpOnly, SameSite, domain, path, and expiry in the actual Set-Cookie response. The scope should match where the cookie is needed. Cookie attributes reduce particular risks but do not replace a valid session check on the server.
Reference: OWASP Session Management Cheat Sheet.
Test transitions and invalidation
Capture a harmless authenticated request, log out, and repeat that request with the old test session. Repeat for a privilege change and a documented expiry boundary. For distributed identity systems, record the stated revocation delay instead of assuming all token types are immediately invalidated.
- Verify server responses rather than only the logged-out screen.
- Check that a newly signed-in session still works.
- Record the token type and transition time for each result.
Review fixation and renewal behavior
Session identity should change appropriately when a caller moves into a higher privilege state. Compare pre-login and post-login session handling without sharing tokens across real users. Add transition tests alongside regular sign-in tests so future login changes preserve the boundary.
Reference: OWASP Session Management Cheat Sheet.
Assessment limits
Token revocation and timeout behavior depends on the application's architecture and documented policy. A cleared cookie only proves a browser-side change. One tested session type does not cover refresh tokens, other devices, or federated identity sessions.
Frequently asked questions
Does clearing a cookie prove logout is secure?
No. Test whether the old authenticated state can still access a protected endpoint, and evaluate that result against the application's session or token revocation policy.
Does HttpOnly prevent every XSS impact?
HttpOnly restricts script access to the cookie. Unsafe scripts may still perform actions within the page's authenticated context, so rendering defects require their own fix.
Should permission changes affect existing sessions?
Define the expected policy, especially for sensitive roles. Test whether the server applies updated permissions or requires renewed authentication as designed.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.