Session hijacking bypasses both passwords and MFA by stealing a cookie. How the attack works, how to defend against it, and what NIS2 and GDPR say about reporting incidents.
Most companies associate cybersecurity with passwords and multi-factor authentication. Session hijacking—the theft of a session cookie—is precisely why this is such a dangerous attack: it bypasses both of these defenses at once. The attacker does not need to log in because they simply “borrow” someone else’s already-logged-in session.
What exactly is a session cookie
When you log in to a web application, instead of having to re-enter your password with every request, the server issues a so-called session token—a random string stored in a cookie in your browser. This token tells the server, “This person is authenticated; trust their subsequent requests.” The problem is that, to the server, the token itself is equivalent to both the password and the second factor combined—whoever possesses it is logged into the system, regardless of how they obtained it.
How a cookie actually falls into an attacker’s hands
The ways in which a session token can be stolen fall into several categories:
- XSS (cross-site scripting) – if a web application is vulnerable to the injection of a malicious script, that script can run in the context of the logged-in user and send the user’s cookie to the attacker. This is the most common method for stealing a session token.
- Network sniffing – on unsecured HTTP communications or on an untrusted Wi-Fi network (e.g., at an airport or in a café), an attacker can intercept data traffic, including cookies, if the entire communication is not encrypted via TLS.
- Infostealer malware – Malicious software installed on the victim’s device can directly read stored cookies from the browser and send them to the attacker, regardless of how strong the original password was.
- Session fixation – an attacker forces the victim to use a pre-known session identifier (for example, via a tampered link), and when the victim logs in, the attacker gains access using the same, already authenticated token.
- Malicious or misconfigured browser extensions – some extensions have access to website content, including cookies, and can exfiltrate them.
The danger of this attack lies in the fact that it appears as completely legitimate activity in the logs—the server has no reason to distinguish the attacker’s request from that of the actual user, since both present the same valid token. As a result, the victim often doesn’t notice the problem until an unexpected change appears in their account.
Technical Defense: A Multi-Layered Approach
No single measure is sufficient on its own—secure session management requires a combination of:
- Cookie attributes: HttpOnly (prevents access to the cookie from JavaScript, thus blocking XSS-based theft), Secure (the cookie is transmitted exclusively over HTTPS), SameSite=Strict or at least Lax (restricts the sending of cookies during cross-site requests and also helps protect against CSRF).
- TLS and HSTS everywhere—no part of the communication should occur over unencrypted HTTP; the HSTS header also prevents downgrade attacks to HTTP.
- Session ID regeneration after login—a token issued before authentication should never be used after authentication; this is a direct defense against session fixation.
- Session time limits—a combination of an idle timeout (logout after inactivity) and an absolute timeout (the session expires after a specified time regardless of activity) shortens the window during which a stolen token is usable at all.
- Re-authentication for sensitive actions—password changes, payment transactions, or email address changes should require fresh identity verification, not just a valid token from a previous session.
- Anomaly detection – linking the session ID to the IP address and User-Agent and monitoring changes to these properties during the session can detect session hijacking before any damage occurs.
- Ability to mass-revoke sessions – the system should be able to revoke all of a user’s active session tokens upon request (for example, after a password change or if an incident is suspected).
Why this is not just a technical issue, but also a compliance issue
For companies subject to NIS2, session hijacking leading to unauthorized access to a system providing an essential or critical service constitutes a serious cybersecurity incident—with the obligation to submit a timely warning to the National Security Authority within 24 hours of detection, a more detailed notification within 72 hours, and a final report within one month (Section 24 of Act No. 69/2018 Coll. on Cybersecurity, as amended by Act No. 366/2024 Coll.; details are regulated by NSA Decree No. 226/2025 Coll.).
If the incident also involves unauthorized access to personal data (for example, through a compromised employee account with access to the CRM), the reporting obligation under Article 33 of the GDPR is also triggered in parallel—the controller must report the personal data breach to the Slovak Data Protection Authority without undue delay, generally no later than 72 hours after discovery. High-quality logging and monitoring is therefore not just a security measure—it also serves as evidence that allows a company to demonstrate exactly when the incident occurred and what its scope was, which is essential for fulfilling both of these parallel obligations within their strict deadlines.
Key Takeaways
Session hijacking serves as a reminder that account security doesn’t end at login—it continues throughout the entire session. A company that invests only in strong passwords and MFA but neglects to properly configure cookies, timeouts, and session monitoring leaves open precisely the window through which both can be bypassed at once.
We’d be happy to help you set up secure session and access management, as well as comply with NIS2 reporting requirements—you can find out more about this service here.
