Session, logout, and token expiry bugs

It is 4pm. A user has spent twenty minutes filling in a long insurance claim form. They click Submit. The page flashes, and they land on the login screen. The form is empty. Nothing was saved.

Nobody wrote a test for that. The login test passed. The form test passed. The bug lives in the gap between them.

This guide covers that gap. You do not need to read the code or know cryptography. You need a browser, two tabs, and about an hour.

Short version

• Test what happens when the token dies during an action, not before it.
• Log out in one tab and check the other tab still open next to it.
• Check that "remember me" actually remembers, and that unchecking it forgets.
• Press the back button after logout. Old pages should not still show data.
• Do not wait an hour for a token to expire. Delete the cookie instead.

---

The words you need first

A few terms come up constantly. Here they are in plain English.

• Session: the period where the app knows who you are. It starts at login and ends at logout or expiry.
• Cookie: a small piece of text the browser stores for a site and sends back on every request.
• Token: a string that proves who you are. The app sends it with each request instead of your password.
• Access token: the short-lived token used for normal requests. Often lasts 15 minutes to an hour.
• Refresh token: a longer-lived token used only to get a new access token. Often lasts days or weeks.
• Silent refresh: when the app swaps an expired access token for a new one in the background, without telling the user.

Most session bugs happen at the moment one of these runs out.

---

Test 1: The token that expires mid-action

This is the highest-value test in the whole area, and almost nobody runs it.

Teams test "log in, wait, reload the page". That is the easy case. The hard case is: the token was alive when the user started typing, and dead when they clicked Submit.

How to run it:

1. Log in as [email protected] on https://staging.example.com.
2. Open a long form. A checkout, a claim, a profile with a file upload — anything that takes more than a minute.
3. Fill in every field. Do not submit yet.
4. Open DevTools with F12. Go to Application > Cookies (Chrome) or Storage > Cookies (Firefox).
5. Find the session cookie. It is usually named something like session, sid, access_token, or connect.sid.
6. Delete that one cookie. Leave everything else alone.
7. Go back to the form and click Submit.

Now watch closely. There are four possible outcomes, and only one is acceptable.

That last row is the dangerous one. The front end shows "Claim submitted" because it never checked the server response. The user walks away happy, and the record does not exist.

Bad: A 401 response comes back, and the app shows "Saved" anyway.

Good: A 401 response comes back, the app shows "Your session expired. Log in again to submit — we saved your answers."

Repeat the same test on any action that costs the user something: payment, upload, bulk delete, sending a message.

---

Test 2: Logout in a second tab

Real users keep tabs open. They log out in one and forget about the other.

How to run it:

1. Log in as [email protected].
2. Open the dashboard in Tab A.
3. Open a second tab (Tab B) to the same app. Go to a different page, such as /settings.
4. In Tab B, click Log out.
5. Switch back to Tab A. Do not reload it.
6. Click something. Load more results, save a setting, open a menu that fetches data.

Tab A should not keep working. The correct behaviour is that the first server call fails and the app sends the user to login.

Common bugs here:

• Tab A keeps loading data because it holds an old token in memory that the logout never cleared.
• Tab A shows an error toast on every click, forever, but never redirects.
• Tab A redirects to login, then bounces back into the app because a "remember me" cookie survived the logout.

Now flip the test. Log out in Tab A, then in Tab B log in as a different user ([email protected]). Go back to Tab A and reload. Does Tab A now show the admin's data with the first user's name still in the corner? That mix-up is common and looks alarming in a screenshot.

---

Test 3: Remember me

"Remember me" sounds simple. It is a checkbox with a lot of hidden rules.

Run these four checks in order. Close the browser fully between each one — not just the tab.

1. Checked, then close and reopen. You should still be logged in. If you are not, the feature does nothing.
2. Unchecked, then close and reopen. You should be logged out. If you are still in, the checkbox is being ignored, and that is a privacy bug on shared computers.
3. Checked, then log out on purpose. Close and reopen. You should be logged out. Logout must beat remember-me.
4. Checked, then change the password from another device. Reopen the remembered browser. The old session should die.

Check the cookie itself too. In Application > Cookies, look at the Expires / Max-Age column. A remembered session shows a real date, often 30 days out. A normal session shows Session, which means the cookie dies when the browser closes. If the "unchecked" case still shows a 30-day date, you have found the bug without clicking anything else.

---

Test 4: The back button after logout

Browsers cache pages. If the server does not say "do not cache this", the browser is happy to show a logged-in page to someone who has logged out.

How to run it:

1. Log in and open a page with private data. An invoice, a salary field, a customer list.
2. Click Log out.
3. Press the browser back button once.

What you should see: the login page, or the private page reloading and then redirecting to login.

What you must not see: the invoice, sitting there, readable. Try scrolling and clicking a link. Sometimes the page renders from cache but every action fails, which still leaks the data on screen.

Repeat after closing and reopening the tab with Ctrl + Shift + T.

---

How to stop waiting an hour

You do not have to sit and watch a clock. Pick whichever trick fits.

1. Delete the cookie. Fastest method. Application > Cookies > right-click > Delete. Reload or click something.
2. Ask for a shorter token. Many teams can set the access token to 60 seconds on staging. Ask a developer for a config flag. This is the most realistic option, because it also tests silent refresh.
3. Edit the cookie value. Change one character in the token string. The server should reject it cleanly, not crash with a 500.
4. Block the refresh call. In the Network tab, right-click the request to /auth/refresh and choose Block request URL. Now the app cannot renew the token, so you see exactly what a user with a flaky connection sees.

Method 4 finds bugs the others miss. A refresh call that fails silently often leaves the app in a half-logged-in state: the menu shows your name, but every list is empty.

---

What to put in the bug report

Session bugs are easy to dismiss as "cannot reproduce", because the trigger is invisible. Your report has to make the trigger obvious.

Include these six things:

1. The exact action that failed, and how long the user had been on the page.
2. How you expired the session (deleted cookie, blocked refresh, waited 60 minutes).
3. The failing network request: URL, method, and status code, such as POST /api/claims 401.
4. The console error text, copied as text, not described.
5. The cookie state after the failure. Which cookies still exist, and their expiry.
6. Whether the data was actually saved on the server. Check with a fresh login.

That last point separates a cosmetic bug from a data-loss bug, and it changes the priority.

Attaching this by hand is slow. A browser tool like Crosscheck captures the screenshot, console logs, network requests, and environment details in one step while you are still on the broken page, which is useful when the state disappears the moment you reload.

---

Frequently asked questions

How long should a session last before it expires?

There is no single right answer, and it is a product decision, not a QA one. Banking apps often use 5 to 15 minutes. Everyday tools use hours or days. Your job is to check that the app behaves correctly at the moment expiry happens, whenever the team has set it.

Is deleting the cookie the same as the token expiring?

Not exactly. Deleting the cookie means the browser sends nothing, so the server sees an anonymous request. An expired token means the server sees a token and rejects it. Both should end at the login screen, but the error path can differ, so test with a short-lived token too when you can.

Why does the app sometimes log me out only after I click something?

Most apps only check the session when they talk to the server. If you sit and read a page, nothing is checked. The logout appears on your next click. That is normal, but the app should still handle that click gracefully.

Should I test session bugs in incognito mode?

Use incognito for a clean starting state, and normal mode for the realistic case. Real users have old cookies, extensions, and multiple tabs. Some session bugs only appear when an old cookie from last month is still sitting there.

Who fixes these bugs, front end or back end?

Usually both. The back end decides when a token dies and returns the right status code. The front end decides what the user sees when that happens. Write the report around the user-visible symptom and include the failing request, and the team can split it themselves.