Session Revocation Failure — “Sign Out All Other Web Sessions” Non-Functional

I wasn't so sure.

While testing an account management feature, I decided to verify whether "Sign Out Everywhere" actually did what it promised. A few browser sessions later, I discovered something unexpected: the sessions that were supposed to be terminated were still very much alive.

Here's how I found it.

What I Found

example.com has a security settings page with a button that says "Sign out all other web sessions." You know the one — every major platform has it. It's supposed to be your emergency brake. If someone steals your session, you smash that button and breathe easier knowing you just kicked them out.

Except it doesn't work. At all.

I tested this across four devices simultaneously — Firefox on Linux, Brave, Chrome, and my phone. That's four active sessions. When I clicked the magic sign-out-everywhere button from one browser, I expected the other three to get booted. Instead, they just sat there, still logged in, still fully functional, completely unbothered.

The button is basically a placebo.

Why It's Broken

There are actually two problems layered on top of each other here.

First problem: The session management panel only ever shows you one session — the one you're currently using. If you're logged in on four devices, the panel will happily tell you there's only one active session. You have no visibility into the others. You can't even see them, let alone revoke them.

Second problem: Even if you could see them, the revocation endpoint behind that button doesn't enforce anything meaningful. I captured the request in Burp Suite and replayed it with all my session cookies intact — 200 OK. Stripped out the session cookies and left only a consent cookie — 200 OK. Removed every single cookie so the request was completely anonymous — still 200 OK. The endpoint just nods and smiles no matter what you send it, without actually terminating anything.

It's the software equivalent of a broken elevator button. The light comes on, but nothing moves.

How I Reproduced It

Part A — The Manual Test

1. Signed up for a new account on example.com using Firefox. This became my "signup browser."

2. Logged into the same account on Brave, Chrome, and my phone. Four sessions total.

3. Checked the session management panel. It showed only the current browser's session. The other three were invisible.

4. Clicked "Sign out all other web sessions." The panel flickered briefly, then went blank.

5. Refreshed the other three browsers. Every single one was still logged in, still active, still able to navigate the site and change account settings.

6. Tried clicking the button from Brave instead. Same result. Zero sessions terminated.

7. Tried from Chrome. Same. The feature is dead no matter where you trigger it from.

Part B — The Burp Suite Deep Dive

1. Fired up Burp Suite as a proxy and intercepted traffic from example.com.

2.Clicked "Sign out all other web sessions" from Firefox and grabbed the request: GET /v1/oauth2/authorize/revoke-other-login-states headed to api.example.com.

3.Replayed it in Burp Repeater with all cookies intact. 200 OK. Fair enough.

4.Stripped out the session cookies (ss, ls, intercom-session) and left only OptanonConsent. Replayed. Still 200 OK. Hmm.

5. Removed every cookie. Completely naked request, no authentication at all. Replayed. 200 OK.

6. Checked the other browsers. Still logged in. Every time. The endpoint never actually revoked anything.

Request 1 — Fully Authenticated

GET /v1/oauth2/authorize/revoke-other-login-states HTTP/2 Host: api.example.com Cookie: ss=182c2fb2–812a-477e-9d8d-aac435420bc200af; ls=b2623493–5a2f-4240-adee-e4a784122709007f; OptanonConsent=[…]; AMP_a331ddf18d=[…]; intercom-session-cjtnalj7=[…] User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0 Referer: https://example.com/ Origin: https://example.com

Response: HTTP/2 200 OK

Request 2 — Session Cookies Removed

GET /v1/oauth2/authorize/revoke-other-login-states HTTP/2 Host: api.example.com Cookie: OptanonConsent=isGpcEnabled=0&[…] User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0 Referer: https://example.com/ Origin: https://example.com

Response: HTTP/2 200 OK (No authentication enforced)

Request 3 — Completely Unauthenticated

GET /v1/oauth2/authorize/revoke-other-login-states HTTP/2 Host: api.example.com Cookie: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0 Referer: https://example.com/ Origin: https://example.com

Response: HTTP/2 200 OK (Still works. No cookies. No session. No nothing.)

Why This Matters

Imagine this scenario. It's not far-fetched. It happens every day.

Someone grabs your session token — maybe through an XSS vulnerability, maybe through malware on your machine, maybe you logged in on a shared computer and forgot to sign out. You notice something weird. A password change email you didn't request. A login from a location you don't recognize. Your stomach drops.

You rush to your account settings, find the security panel, and click that reassuring button: "Sign out all other web sessions." The page responds. Maybe it even shows a little confirmation message. You exhale. You're safe now, right?

Wrong. The attacker's session never got touched. They're still in your account. They can still see everything. And you have no idea, because every indicator the platform gave you said the opposite.

That's the impact here. Not a theoretical vulnerability, but a real, human moment of false trust. The feature that's supposed to be your last line of defense is just theater.

How to Fix It

I'm not here just to break things. I want to help fix them too. Here's what I'd suggest:

1.Actually track every session. Right now it feels like the system only keeps one session record and overwrites it. Every login from every device should create its own independent session in the database. INSERT, never upsert.

2. Show users all their sessions. IP address, browser, device type, login timestamp, rough location. Let people see what's out there so they can make informed decisions.

3. Put authentication on the revocation endpoint. A request to sign out other sessions should fail hard if it doesn't come with valid credentials. Right now it accepts anything.

4. Validate tokens on every request. If a session was supposed to be revoked, the token should stop working server-side. A blacklist or revocation timestamp would do the trick.

5. Switch from GET to POST or DELETE. Revoking sessions is a state-changing action. It shouldn't be a GET request. Add a CSRF token while you're at it.

6. Return proper JSON responses. The endpoint currently returns text/html. It should return application/json with meaningful status information.

A Few Other Things I Noticed

1. The session panel shows the raw User-Agent string instead of a clean, human-readable browser and OS name. Minor, but it makes the panel harder to parse at a glance.

2. You only ever see one session. Always. Even when you're logged in on multiple devices. The panel doesn't give you the full picture.

3. The revocation endpoint returns HTML instead of a proper API response. Feels like it wasn't designed to be consumed programmatically.