Session Hijacking
Session hijacking is an attack where an adversary takes over a legitimate user's session by obtaining or forging their session identifier, gaining unauthorized access to their account.
Understanding Session Hijacking
Web applications use session identifiers — typically stored in cookies or tokens — to maintain authenticated state across requests. Session hijacking occurs when an attacker obtains this identifier and uses it to impersonate the victim. The server cannot distinguish between the real user and the attacker because the session ID is the sole proof of identity.
Session theft can happen through several vectors. Cross-site scripting (XSS) allows JavaScript to read session cookies if they lack the HttpOnly flag. Network sniffing on unencrypted HTTP connections exposes cookies in transit. Session fixation forces a known session ID onto a victim before they authenticate, so the attacker already knows the post-login session ID. Malware and browser extensions with sufficient permissions can also extract session data.
Session fixation is a subtly different attack where the adversary sets a session ID before the user logs in. If the application does not regenerate the session ID upon authentication, the attacker's pre-set ID becomes a valid authenticated session. This is why session regeneration after login is a critical defense.
Key defenses include setting the HttpOnly flag on session cookies (prevents JavaScript access), the Secure flag (prevents transmission over HTTP), the SameSite attribute (prevents cross-origin cookie sending), regenerating session IDs after authentication, implementing session timeouts, and binding sessions to client characteristics like IP address or user agent.
Why This Matters for Vibe-Coded Apps
AI-generated authentication code often stores session tokens in localStorage for simplicity, which makes them accessible to any JavaScript running on the page — including XSS payloads. Vibe-coded apps should use httpOnly cookies for session storage whenever possible, but AI tools rarely configure this because it requires server-side cookie management rather than simple client-side token storage.
When reviewing AI-generated auth, check where tokens are stored. If they are in localStorage or sessionStorage, they are vulnerable to XSS-based theft. If they are in cookies, verify the HttpOnly, Secure, and SameSite flags are set. Supabase and Firebase handle token storage securely by default, but custom auth implementations generated by AI often do not.
Real-World Examples
Firesheep Extension (2010)
The Firesheep Firefox extension automated session hijacking on public WiFi networks by sniffing unencrypted HTTP traffic for session cookies from sites like Facebook, Twitter, and Amazon. It could steal sessions with a single click, affecting millions of users on open networks.
GitHub Session Token Exposure (2022)
Heroku and Travis CI OAuth tokens stored in GitHub session management were compromised, allowing attackers to access private repositories of organizations including npm. The stolen session tokens provided the same access as the legitimate users without needing their passwords.
Zoom Session Token Theft via Link Preview
A vulnerability allowed Zoom meeting URLs containing session tokens to be captured by link preview services. When a Zoom link was shared in chat platforms, the preview fetcher would access the URL, potentially capturing the embedded session token and allowing unauthorized meeting access.
Frequently Asked Questions
What is the difference between session hijacking and session fixation?
Session hijacking steals an existing valid session token after the user has authenticated. Session fixation is a preemptive attack where the adversary forces a known session ID onto the victim before they log in, so the attacker already has the ID when it becomes authenticated. The defense against fixation is regenerating the session ID upon login, which invalidates any pre-set values.
Does HTTPS prevent session hijacking?
HTTPS prevents session hijacking via network sniffing by encrypting all traffic including cookies. However, it does not prevent hijacking through XSS (stealing cookies via JavaScript), session fixation, malware, or cross-site attacks. HTTPS should be combined with HttpOnly cookies, SameSite attributes, and session timeouts for comprehensive protection.
Should I store session tokens in cookies or localStorage?
Cookies with HttpOnly, Secure, and SameSite flags are more secure for session tokens. HttpOnly prevents JavaScript access, protecting against XSS-based theft. localStorage is accessible to any JavaScript on the page, making it vulnerable to XSS. If you must use localStorage (for example, with certain SPA authentication flows), ensure you have robust XSS protection including a strict CSP.
How long should a session last?
It depends on the sensitivity of the application. Banking and financial applications typically expire sessions after 15-30 minutes of inactivity. General web applications commonly use 30 minutes to a few hours. Remember-me functionality can extend this with a separate long-lived token, but the session for sensitive operations should still require re-authentication. Always implement absolute session timeouts (maximum total duration) in addition to idle timeouts.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to session hijacking and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan