Session fixation: An underestimated threat
Session fixation rarely receives the same level of attention as vulnerabilities such as XSS or SQL injection. The reason is simple: it’s less visible, harder to understand, and does not present itself as a classic break-in.
Yet the outcome is the same from a business perspective, as unauthorised access to user accounts, often without any obvious signs.
What is session fixation?
A properly designed web application generates a new session identifier (session ID) after every successful login. This is the value that allows the system to recognise an authenticated user.
If this does not happen, and the application continues to use an existing session, the door is left open for exploitation.
Session fixation is based on a simple principle: the attacker does not steal an existing session but creates one and forces the victim to use it. The process typically looks like this:
- The attacker generates a known session ID.
- Delivers it to the victim’s browser by some means.
- The victim logs into the application.
- The system fails to issue a new session ID and continues using the existing one.
From that point onwards, both the attacker and the victim share the same session. From the application’s perspective, there is no distinction between them.
What risk does it actually pose?
The consequences are comparable to other account takeover scenarios. The attacker can access data, perform actions on behalf of the user, and in some cases take full control of the account.
This becomes particularly critical when the application does not require re-authentication for sensitive operations. In such cases, an attacker may change passwords or authentication details, effectively locking the legitimate user out.
The real challenge lies in detection. All actions originate from a valid session with a legitimate identifier. As a result, server-side logs often show no clear anomaly.
This is where a technical weakness becomes a business risk: the access is not only unauthorised but also difficult to trace after the fact.
How does it become exploitable?
Session fixation can exist on its own, but in practice, it’s often combined with other vulnerabilities. A common example is cross-site scripting (XSS). However, it’s important to clarify a frequent misconception: eliminating XSS alone does not remove the risk.
The core requirement for a successful attack is always the same: the attacker must ensure that a session identifier of their choosing is set in the victim’s browser. This can be achieved in several ways.
In shared device environments – such as workplaces, public terminals or educational institutions – an attacker with physical access can directly set the required cookie in the browser.
In XSS-based scenarios, malicious client-side code is executed in the victim’s browser. If the session cookie is protected with the HttpOnly flag, it cannot be modified directly. However, workarounds exist. One such technique is Cookie Jar Overflow, which exploits browser limits on the number of stored cookies, eventually forcing the original session cookie to be removed and replaced with one controlled by the attacker.
Network-based attacks also play a role. If protections such as the Secure flag or HSTS are missing, a man-in-the-middle attacker may intercept and modify server responses, injecting a chosen session identifier.
A less obvious but realistic risk is subdomain compromise. If the application does not use host-only cookies, a compromised subdomain may be able to set cookies that are valid for the main domain.
It’s also important to note that session identifiers aren’t limited to cookies. They may also be transmitted via HTTP headers or URL parameters, and the vulnerability remains relevant in those cases.
Why doesn’t vulnerability scanning always detect it?
Session fixation is a good example of the limitations of purely tool-based security assessments. Automated scanning can check cookie attributes, identify known vulnerabilities, and flag configuration issues. However, session fixation is not simply a configuration flaw; it’s a behavioural issue within the application logic.
The key question is not whether a flag is set correctly, but what happens after authentication. This can only be reliably tested through manual assessment. A tester sets a predefined session identifier and verifies whether the application replaces it after login. If it doesn’t, the vulnerability is present. This is where traditional, purely automated testing often falls short.
How to mitigate the risk effectively
The most important control is straightforward: generate a new session identifier after every successful login. This is not a best practice; it’s a baseline requirement.
Beyond that, proper session and cookie handling significantly reduces exposure. The most relevant measures include:
- using appropriate cookie prefixes (e.g. __Host-);
- applying the SameSite attribute (preferably “Strict”);
- setting the HttpOnly flag;
- enforcing the Secure flag;
- using host-only cookies.
It’s also advisable to bind sessions to certain client characteristics, such as IP address or user agent. While not foolproof, this increases the cost of exploitation.
From a user perspective, visibility matters. Allowing users to view and terminate active sessions reduces their exposure. And one often-overlooked principle: logging out must invalidate the session on the server side, not just in the browser.
Why does it remain under the radar?
Session fixation is not a headline-grabbing vulnerability. It doesn’t break databases, does not leave obvious traces, and often exists in the shadow of more visible issues.
That is precisely what makes it dangerous! The attack appears legitimate, the access is real, and the impact directly affects user trust. A seemingly technical detail quickly becomes a tangible business risk.
Organisations that recognise this early are not just fixing a vulnerability – they are strengthening their overall security posture.
If you want to understand how your application behaves under real attack conditions, relying solely on automated tools is rarely enough. Get to know your options with us!
