Cybersecurity glossary
What is an HttpOnly Cookie?
Learn what the HttpOnly cookie attribute does, how it prevents document.cookie access, why it reduces XSS session theft, and which cases still need additional defenses.
Definition
An HttpOnly cookie is a cookie marked with the HttpOnly attribute so that browsers withhold it from non-HTTP APIs such as document.cookie, preventing page JavaScript from reading or writing that cookie directly.
Why HttpOnly matters
Cross-site scripting frequently aims at session cookies. If malicious script can call document.cookie, it can exfiltrate a session identifier to an attacker server in one request. Marking a cookie HttpOnly closes that direct read path.
HttpOnly is one of the highest-value, lowest-cost cookie flags for authentication. It is also one of the most misunderstood: teams sometimes believe it “makes XSS harmless,” which is not true.
How HttpOnly works
The attribute is set on Set-Cookie. Browsers keep the cookie for HTTP messaging but exclude it from the script-visible cookie string.
Server sets HttpOnly
Set-Cookie includes the HttpOnly attribute on a sensitive cookie such as a session ID.
Browser stores the cookie normally
Scope rules for Domain, Path, Secure, and SameSite still apply.
Matching requests include it
The Cookie header still carries the value to the server automatically.
Script APIs omit it
document.cookie and equivalent page script interfaces cannot read or write that cookie.
What HttpOnly does and does not cover
| Scenario | HttpOnly helps? | Notes |
|---|---|---|
| XSS tries to read session via document.cookie | Yes | Primary benefit |
| XSS triggers authenticated fetch/XHR as the user | No | Cookie still attaches to same-origin requests |
| Network attacker on cleartext HTTP | No | Need HTTPS + Secure (and HSTS) |
| CSRF from another site | No | Need SameSite and/or anti-CSRF tokens |
| Legitimate JS must read a preference cookie | N/A | Cannot use HttpOnly for that cookie |
Design guidance
Default HttpOnly for sessions
Any cookie that only the server needs should be HttpOnly by default.
Keep client tokens elsewhere carefully
If SPA code needs a token, prefer architectures that avoid putting long-lived secrets in JS-readable storage.
Pair with Secure and SameSite
HttpOnly alone is incomplete session hygiene.
Still prevent XSS
HttpOnly reduces theft of the cookie string; it does not remove in-browser session abuse.
Implementation checklist
- Mark authentication and server session cookies HttpOnly.
- Verify frameworks do not expose session cookies to the client bundle.
- Combine HttpOnly with Secure on HTTPS sites.
- Choose SameSite according to CSRF and cross-site flow requirements.
- Avoid putting bearer tokens in localStorage when an HttpOnly cookie session is viable.
- Test that document.cookie does not reveal the session name/value.
- Remember mobile webviews and older embedded browsers in compatibility tests.
- Treat missing HttpOnly on session cookies as a finding in security reviews.
The practical takeaway
An HttpOnly cookie is withheld from page JavaScript while still being sent on HTTP requests. That blocks a classic XSS technique for stealing session identifiers.
Use HttpOnly on every cookie the client script does not need to read, then continue investing in XSS prevention, CSRF controls, and transport security—because automatic cookie attachment still lets injected script act as the user.
Related security terms
Secure Cookie
Companion attribute that limits cookies to HTTPS transport.
SameSite Cookie
Controls cross-site sending; complements HttpOnly for session cookies.
Cross-Site Scripting (XSS)
Injection class that often targets readable session cookies when HttpOnly is missing.
Cookie
General cookie model and attribute overview.
Frequently asked questions
What does HttpOnly mean on a cookie?
It tells the browser that JavaScript running in the page must not access that cookie through document.cookie or similar script interfaces. The cookie is still sent on matching HTTP requests.
Does HttpOnly stop XSS?
No. HttpOnly reduces one common XSS impact—stealing the cookie value—but attacker script can still perform actions as the user by triggering requests that automatically include the cookie.
Should every cookie be HttpOnly?
Authentication and most server-side session cookies should be HttpOnly. Cookies that legitimate client JavaScript must read (rare) cannot use HttpOnly.
Can XSS still overwrite an HttpOnly cookie?
Page script generally cannot read or set HttpOnly cookies via document.cookie. Other cookie-setting vectors (headers, subdomain issues, browser bugs) are separate concerns.
Is HttpOnly enough for session security?
No. Combine it with Secure, appropriate SameSite, short lifetimes, server-side invalidation, CSRF defenses, and XSS prevention.
How do you set HttpOnly?
Include HttpOnly in the Set-Cookie header, for example: Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax.
Does HttpOnly hide cookies from the user?
No. Users and browser developer tools can still inspect cookies. HttpOnly only blocks document script access.
References
Explore authoritative guidance and frameworks related to httponly cookie.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.