Testing Logout When CSRF Tokens Rotate, Forms Go Stale, and Another Tab Is Still Logged In

Logout looks simple until you test it under real constraints. A secure logout endpoint may require a valid CSRF token, a session may expire between page load and form submit, and a second tab may still show an authenticated UI after the first tab has already revoked the session. Those are not edge cases to hand-wave away, they are the cases that decide whether a web app behaves predictably under normal user behavior.

The key distinction is this: CSRF protection prevents a third-party site from triggering state-changing requests on behalf of a user, while session revocation decides what happens after the user intentionally logs out. You need to test both. A logout flow can be secure but confusing if stale tabs keep rendering private data, or can be user-friendly but insecure if logout is exposed to cross-site request forgery.

This article shows a small, reproducible QA project for test csrf protected logout flows, with three things most suites miss:

1. a fixture that rotates or expires hidden tokens,
2. logging that makes token refresh behavior visible, and
3. a multi-tab check that proves session state is cleaned up consistently.

What we are actually testing

There are three related behaviors, and it helps to keep them separate when you write assertions.

1) CSRF validation on logout

The server should reject logout if the CSRF token is missing, expired, or invalid. OWASP’s Cross-Site Request Forgery Prevention Cheat Sheet is the right baseline for why logout can be protected at all.

2) Session revocation after logout

After a successful logout, all requests that depend on the old session should fail. That includes API calls, page reloads, and navigation in another tab that still has the old cookie jar or in-memory state.

3) Cross-tab UI cleanup

The UI in another tab should not keep pretending the user is authenticated. That may mean a forced redirect to /login, a polite “session expired” message, or a blocked action that demands reauthentication. The exact UX is a product choice, but it should be consistent.

A logout test that only checks the current tab is incomplete. The risky part is usually the tab the user forgot was open.

A small fixture that makes the failure modes visible

You do not need a full production app to validate this behavior. A tiny fixture is enough if it reproduces the mechanics:

• login sets an HTTP-only session cookie,
• /account renders a hidden CSRF token in a logout form,
• /logout accepts only POST,
• the server rotates the token on page load or after a short TTL,
• an authenticated /api/me endpoint returns 401 after logout.

Here is a minimal HTML form that mirrors the issue without adding extra app logic:

```html
<form method="post" action="/logout">
  <input type="hidden" name="csrf_token" value="" />
  <button type="submit">Log out</button>
</form>

On the server, make token freshness visible in logs. The exact framework does not matter as much as the signal you record.

text
[auth] issued csrf token 8f3c... for session 91a2...
[auth] validated logout csrf token for session 91a2...
[auth] revoked session 91a2...
[auth] rejected logout, stale csrf token for session 91a2...


Those log lines are useful because they let your test explain *why* a logout failed, not just that it failed.

## Test design: use one browser context, two pages

For this scenario, a single browser context with two pages is the right starting point. That keeps cookies and storage shared, which is exactly what you want when checking session revocation in browser automation.

If you create separate contexts, you may accidentally test two independent sessions instead of one user with two tabs.

### Why this matters

- **One context, two pages** simulates the same logged-in user opening a second tab.
- **Separate contexts** are better for isolated users, but they hide cross-tab state bugs.

## Playwright project setup

Playwright is a good fit here because it gives you explicit control over browser contexts and pages, and the test code stays readable. See the official [Playwright docs](https://playwright.dev/docs/intro) for installation and runner setup.

A minimal test file might look like this:

```typescript
import { test, expect } from '@playwright/test';

test('logout revokes the session in both tabs', async ({ browser }) => {
  const context = await browser.newContext();
  const pageA = await context.newPage();
  const pageB = await context.newPage();

  await pageA.goto('http://localhost:3000/login');
  await pageA.fill('input[name="email"]', 'user@example.com');
  await pageA.fill('input[name="password"]', 'password123');
  await pageA.click('button[type="submit"]');

  await pageA.goto('http://localhost:3000/account');
  await pageB.goto('http://localhost:3000/account');

  await pageA.click('button:text("Log out")');
  await expect(pageA).toHaveURL(/\/login/);
  await expect(pageB).toHaveURL(/\/login/);
});

That is the happy path. It is not enough.

Add token freshness checks, not just UI checks

If the logout form contains a hidden token, test the stale-token path explicitly. A flaky suite often passes because it only tests the fresh-page path.

Case 1, token expires before submit

test('rejects logout with an expired hidden CSRF token', async ({ page }) => {
  await page.goto('http://localhost:3000/account');
  await page.waitForTimeout(3000); // shorter than token TTL in the fixture
  await page.click('button:text("Log out")');
  await expect(page.getByText('Your session expired, refresh and try again')).toBeVisible();
});

Case 2, token rotates after page load

A stronger fixture rotates the token when the page is re-rendered or when the session is refreshed. The test should prove the old token no longer works.

test('rejects a stale logout form after token rotation', async ({ page }) => {
  await page.goto('http://localhost:3000/account');
  const tokenBefore = await page.locator('input[name="csrf_token"]').inputValue();

  await page.reload();
  const tokenAfter = await page.locator('input[name="csrf_token"]').inputValue();
  expect(tokenAfter).not.toBe(tokenBefore);

  await page.locator('form').evaluate((form) => {
    const input = form.querySelector('input[name="csrf_token"]');
    if (input) input.setAttribute('value', tokenBefore);
  });

  await page.click('button:text("Log out")');
  await expect(page.getByText('Invalid or expired CSRF token')).toBeVisible();
});

The point is not to simulate a browser quirk, it is to prove the server does not trust a stale hidden field.

Verify logout in the other tab after revocation

This is the part many teams leave untested. One tab logs out, the other tab should stop working in a deterministic way.

A useful pattern is to assert three things in the second tab:

1. the UI transitions away from authenticated content,
2. a protected route redirects or fails,
3. an authenticated API request returns 401 or 403.

test('second tab loses access after logout in the first tab', async ({ browser }) => {
  const context = await browser.newContext();
  const a = await context.newPage();
  const b = await context.newPage();

  await a.goto('http://localhost:3000/login');
  // login steps omitted for brevity
  await a.goto('http://localhost:3000/account');
  await b.goto('http://localhost:3000/account');

  await a.click('button:text("Log out")');

  const response = await b.request.get('http://localhost:3000/api/me');
  expect(response.status()).toBe(401);
  await expect(b).toHaveURL(/\/login/);
});

If your app uses client-side state, consider listening for a storage event or a broadcast channel message to force a local UI update. That is an application decision, but the test should check the actual behavior you expect, not an idealized version.

Failure cases worth keeping in the suite

A small suite is better than a broad one if it covers the cases that break silently.

Stale form submission

If the hidden token is older than the server allows, logout should fail cleanly without revoking the active session.

Partial revocation

If the logout request succeeds but one tab still fetches user data from cache, the UI may lie. The test should reload or call a protected endpoint after logout.

Missing cross-tab cleanup

If one tab logs out but another tab still shows private data until a manual refresh, that is not a CSRF failure, it is a session-state consistency failure.

Replayed logout request

Submitting the same logout request twice should not create a confusing mixed state. The second request can be idempotent, but it should not resurrect the session.

Debugging checklist when the test fails

When a logout test flakes, the root cause is usually one of four things.

1. Token timing is too aggressive, the fixture TTL is shorter than the page interaction time.
2. The server rotates tokens on a different event than the test expects, such as response rendering versus login.
3. Cookies are scoped unexpectedly, which can make one tab look logged out while another still carries auth state.
4. The UI is reading stale client state, so the page looks authenticated even though the server already revoked the session.

A practical debugging step is to log three timestamps together: token issue time, logout submit time, and session revoke time. If the revoke time precedes the submit time, your test is probably fighting a fixture bug, not the product.

A compact decision framework for teams

Use this when deciding how much to automate.

If your app has a simple server-rendered session model, these tests are usually enough. If your app has aggressive client caching, websockets, or cross-tab auth sync, add an explicit test for the state channel you use.

What I would keep, and what I would skip

Keep the tests that prove server-side security and browser-visible consistency. Skip tests that only repeat the same assertion through different selectors. A logout suite does not need ten variations of the same redirect check.

If you only have time for one test, make it the multi-tab revocation test with a protected API assertion. That catches more real regressions than a single-form submit check.

FAQ

Should logout always use CSRF protection?

If logout changes server-side session state, yes, treat it as a state-changing request and protect it accordingly. OWASP recommends protecting state-changing operations against CSRF.

Is a GET logout ever acceptable?

It is easier to implement, but it is a poor default because a cross-site request can trigger it unintentionally. Use POST unless you have a very specific legacy constraint and a documented risk review.

How do I know if the second tab really lost the session?

Do not rely on the visible page alone. Assert a protected API call, a page reload, or both.

What is the best way to test hidden token expiration?

Force a short TTL in a fixture and verify that a previously rendered form is rejected after the TTL passes or after token rotation.

Should cross-tab logout update happen automatically?

That depends on your product design. What matters for testing is that the behavior is defined, repeatable, and enforced on both the server and the client.

If you turn logout into a small, reproducible browser project instead of a one-click smoke test, you get stronger signal from fewer assertions. The suite stays focused on the real risks: stale hidden tokens, revoked sessions, and tabs that still think they are trusted.