What matters first
- Use appropriate transport and cookie controls for the application’s authentication model.
- Verify session changes after sign-in, recovery, and privilege changes.
- Test invalidation on the server rather than only disappearance from the browser.
Map the complete session lifecycle
Document anonymous and authenticated sessions, identity-provider exchanges, refresh behavior, and the point at which an account is considered logged out. Include mobile and integration clients if they share authentication services. Different clients may use different token or cookie models.
Agree the expected behavior for account disablement, password recovery, suspected session theft, and administrator privilege removal. A test cannot establish whether a long-lived session is acceptable unless the product has a policy for the sensitive actions that session can perform.
Review transport and browser controls
Use HTTPS and appropriate Secure, HttpOnly, and SameSite settings for authentication cookies. Review domain and path scope so a cookie is not unnecessarily available to unrelated application surfaces. Check the behavior through your actual proxy and deployment configuration, not just the local development settings.
Understand what each control does. HttpOnly limits script access to the cookie value, but an XSS issue can still cause actions in the user’s browser. SameSite can reduce some cross-site request risks, but it should be evaluated with the application’s CSRF defenses and supported workflows.
Check renewal, invalidation, and privilege changes
Verify that authentication and relevant privilege transitions establish the intended session state. Review expiry, refresh, and revocation behavior together so an expired access token is not silently replaced through a still-valid recovery path the team forgot to consider.
Test logout and administrative invalidation against an existing session using controlled accounts. Check whether role removal or organization membership changes take effect for active sessions and queued work. A frontend redirect to a login page is not evidence that the server will reject a prior credential.
Make the results operationally useful
Record the browser, account state, deployed version, and expected session policy for each finding. Separate a missing protective flag from a demonstrated access-control failure, while explaining how configuration affects the application’s risk. Avoid treating a cookie scan score as a complete session assessment.
Preserve regression tests for recovery, logout, and role changes, and review what authentication events are logged. Logs should help investigate account activity without storing raw session identifiers, tokens, or other credentials that would create a second exposure path.
Your next steps
- Document expiry, refresh, logout, recovery, and role-change expectations.
- Inspect cookie settings and transport behavior in the deployed environment.
- Verify server-side invalidation with controlled accounts and prior sessions.
- Discuss a scoped identity and session review before changing authentication flows.
Questions teams ask
Does HttpOnly eliminate XSS risk?
No. It restricts JavaScript access to the cookie value, but injected code may still perform actions in the authenticated browser context.
Is clearing a cookie enough to revoke a server session?
It removes that browser’s copy. The server’s acceptance and revocation behavior must also match the intended policy, including previously captured credentials.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .