Session Logout Testing: Do Old Cookies Still Work?

Session logout testing checks whether cookies and tokens issued before a logout remain valid for authenticated requests after the logout occurs. You test this by capturing the pre-logout cookies/tokens, logging out, and then replaying those captured values against protected endpoints to see if the server still accepts them. A correct implementation invalidates the session server-side, so the old credentials are rejected with a 401 Unauthorized response.

Why Session Logout Testing Matters

Many web applications rely on cookies (like session IDs) or tokens (like JWTs) to maintain user authentication. When a user clicks “Log Out,” they expect that their session is terminated and that anyone with the old credentials cannot access their account. However, developers often only remove the cookie from the browser, leaving the server-side session active. This is a common security flaw called “logout without server-side invalidation.” An attacker who has stolen the cookie or token can continue using it indefinitely. Testing whether old cookies and tokens still work after logout is a critical part of security validation, especially for applications handling sensitive data like banking, healthcare, or enterprise systems.

How Session Invalidation Works

To understand the testing, you need to know how sessions are managed. There are two main approaches:

Server-side sessions: The server stores session data (e.g., in memory, database, or Redis) and sends the client a session ID cookie. Logout deletes the server-side session record, making the cookie useless.
Token-based (stateless) sessions: The server signs a token (like a JWT) and sends it to the client. The server does not store the token; it just verifies the signature on each request. Logout cannot invalidate a stateless token unless the server keeps a blocklist of revoked tokens or uses short-lived tokens with a refresh mechanism.

For cookies, the Expires or Max-Age attribute controls when the browser deletes it, but that only affects the client. The server must also delete its session record. For tokens, the server must implement an explicit revocation mechanism, such as a denylist or a token version number stored in the database.

How to Test Old Cookies and Tokens

Here is a step-by-step method to test whether old cookies and tokens still work after logout:

Log in to the application using a test account. Use browser developer tools (Network tab) or a tool like Postman or cURL to capture the authentication cookie (e.g., sessionid) or token (e.g., Authorization: Bearer ...).
Perform a normal logout through the application’s UI, or by calling the logout API endpoint. Note whether the server responds with a success message.
Replay the captured cookie/token against a protected endpoint, for example, GET /api/profile or GET /account. Use a tool like cURL:

curl -i -H "Cookie: sessionid=abc123" https://example.com/api/profile
curl -i -H "Authorization: Bearer eyJhbGciOi..." https://example.com/api/profile

If the server responds with 200 OK and returns user data, the session was not invalidated server-side. If it responds with 401 Unauthorized or 403 Forbidden, the logout worked correctly.

What to Check Beyond the Basic Replay

The basic replay test is essential, but there are additional scenarios to cover:

Multiple sessions: Log in from two browsers, log out from one, and verify the other session still works. Then log out from the second and verify it is also invalidated.
Token expiration: If using tokens, check that an expired token is rejected even before logout, and that a token with a future expiration is rejected after logout (if the server implements revocation).
Refresh tokens: If your app uses refresh tokens to get new access tokens, test that the refresh token is also revoked after logout. Replay the refresh token to see if it can still mint new access tokens.
Cookies with different scopes: Some cookies are set for a specific path or domain. Test that a cookie set for /admin is not valid for /user after logout, and vice versa.
Server-side session expiry: Even if the session is not invalidated on logout, it may have a timeout. Check that the session expires after the configured idle time or absolute timeout.

Common Problems and Misconceptions

One common misconception is that clearing cookies in the browser is the same as logging out. It is not. Clearing cookies only removes the credential from the client; the server-side session remains active. Another issue is that some developers rely on the Secure or HttpOnly flags to protect cookies, but these do not invalidate the session. A stolen cookie from an XSS attack can still be replayed. Also, many people assume that JWT logout is automatic because the token is stateless, but that is false. Without a revocation mechanism, a JWT remains valid until it expires. Finally, be aware that some applications use a “soft logout” that only marks the session as inactive but does not delete it, which can be a security risk if the session ID is reused.

Tools and Techniques for Testing

You can perform these tests manually with browser dev tools, but for repeatable testing, consider using:

Burp Suite or OWASP ZAP: Intercept the traffic, capture cookies/tokens, and replay requests after logout.
Postman: Save the login response cookies and use them in a new request after logging out.
Automated scripts: Write a script that logs in, captures the cookie, logs out, and then tries the cookie against a protected endpoint. This can be integrated into CI/CD for regression testing.

When testing, always use a dedicated test account and never use production data. Also, be careful not to violate any laws or terms of service; only test applications you own or have explicit permission to test.

How to Fix a Failed Logout

If you find that old cookies or tokens still work after logout, here is how to fix it:

Server-side sessions: In the logout handler, delete the session record from the server-side store (e.g., session.destroy() in Express, or session.invalidate() in Java). Also, clear the session cookie by setting its expiration to a past date.
Token-based sessions: Maintain a blocklist of revoked token IDs (the jti claim) in a fast store like Redis. Check this blocklist on every authenticated request. Alternatively, use a token version number stored in the user’s record; increment it on logout and include the version in the token signature.
Refresh tokens: Store refresh tokens in a database with a revocation flag. On logout, set the flag to revoked. Also, rotate refresh tokens on each use to prevent replay.

After implementing a fix, re-run the tests to confirm that the old credentials are rejected.

Frequently Asked Questions

Can a JWT be invalidated on logout?

Yes, but only if you implement a revocation mechanism. Since JWTs are stateless, the server cannot automatically know a token is revoked unless you check a blocklist or a version number. Without that, a JWT remains valid until its expiration.

Is it enough to delete the cookie on the client side?

No. Deleting the cookie only removes it from the browser. The server-side session is still alive. An attacker who has already stolen the cookie can still use it. You must also invalidate the session on the server.

What is the difference between session timeout and logout?

Session timeout automatically ends a session after a period of inactivity or an absolute maximum lifetime. Logout is an explicit user action to end the session immediately. Both should invalidate the server-side session, but they are triggered differently.

Should I test logout on mobile apps too?

Yes. Mobile apps often use tokens stored in secure storage. Test that the token is removed from the device and that the server rejects it after logout. The same principles apply as for web apps.

How often should I run logout tests?

Run them as part of every release that changes authentication logic, and at least once per quarter as a security regression test. Automated tests can be added to your CI pipeline to catch regressions early.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →