Security research is rarely about a single "gotcha" moment. More often, it's about persistence, clear communication, and standing your ground when something feels wrong, even if the initial response says otherwise.
While working as a developer, I gradually developed an interest in working with companies through Vulnerability Disclosure Programs (VDPs) finding security issues, understanding how they work, and responsibly reporting them.
It's a challenging space. Sometimes organisations immediately recognise the impact of a bug and act on it quickly. Other times, even issues that could have serious consequences aren't always seen the same way. That difference in perspective is part of what makes security research both difficult and interesting.
For this write-up, I'm intentionally keeping the company name anonymous. This is to respect the terms of responsible disclosure and the agreements made during the reporting process.
While testing REDACTED, I noticed something subtle but alarming:
Session tokens remained valid even after a user logged out.
At first glance, this might sound harmless. But in practice, it means that anyone who gains access to a valid session token can reuse it indefinitely, even after the legitimate user believes they've ended their session.
This violates a core principle of secure session management: logout must invalidate the session server-side.
Why this matters?
The issue was not how a token was obtained, that's often debated in these programs.
While some big programs accepts similar reports for example Shopify https://hackerone.com/reports/1172205 , Dust https://hackerone.com/reports/3101207 it's not always the case. Due to the size of users in this instance, I decided to give it a shot.
The issue was simpler and more fundamental:
- Session tokens were not invalidated on logout
- Tokens remained reusable across browsers and devices
- Tokens did not immediately expire
- Reusing a token granted full authenticated access
This turns any token leakage, from browser extensions, MITM attacks, or shared devices, into a persistent account takeover risk.
Proof of Concept: Demonstrating Real Impact
To avoid ambiguity, I demonstrated the issue using controlled, ethical testing methods with multiple test accounts.
Method 1: DevTools / Cookie Replacement (Controlled Environment)
- Log into Account A
- Extract the session token
- Log out
- Log into Account B on a different browser
- Replace Account B's session token with Account A's token
- Result: Account A is fully accessible
The token remained valid after logout and across sessions.
Method 2: OWASP ZAP (Session Hijacking Simulation)
Using OWASP ZAP:
- Captured authenticated requests
- Extracted session cookies
- Replayed them in a different browser context
Again, the token was reusable and granted full access.
This closely mirrors what happens during MITM attacks on insecure networks, such as public Wi-Fi.
Initially I got a response from the Hackerone triage team -
The Pushback — and Why I Didn't Drop It
The initial response labeled the report Not Applicable, arguing that:
- Obtaining session cookies is not a valid prerequisite
- No direct impact was demonstrated
But session management vulnerabilities do not rely on a single attack vector. Their danger lies in what happens once a token leaks — by any means.
So I responded with:
- OWASP references
- Comparable resolved reports from other platforms
- Additional POCs
- Clarification that tokens never expired and survived logout
The Turning Point
After further discussion with the security and product teams, a staff member of the company had a closer look and it was acknowledged that:
- Sessions were valid for 30 days by default
- Logout did not immediately invalidate tokens
- This behavior, while framework-default, posed unnecessary risk
The issue was eventually reopened and reassessed, and recommendations were made to invalidate sessions immediately on logout. Although the report was later marked as a duplicate, no action had been taken during that period.
The reply from the staff
After the changes were implemented, I checked again a month later to see if they had actually taken effect and they had. For me, that felt like a real win.
Lessons Learned
- Security isn't just about exploits, it's about risk amplification
- Framework defaults are not always secure defaults
- Clear reasoning > sensational exploits
- Persistence matters more than instant validation