HttpOnly cookies are cookies that cannot be accessed through client-side JavaScript, providing protection against XSS attacks attempting to steal session tokens. This attribute ensures that even if an attacker manages to execute malicious scripts, they cannot directly access these cookies. It's a crucial security measure for session management and authentication.
An HttpOnly cookie is one the server marks with the HttpOnly attribute in its Set-Cookie header. That single flag tells the browser to keep the cookie out of reach of client-side scripts: it is still attached automatically to matching HTTP requests, so the application works normally, but JavaScript running on the page cannot read or write it through document.cookie or the Cookie Store API. The attribute is aimed squarely at session and authentication cookies, the ones an attacker most wants. It does not change how the cookie is transmitted or scoped; that is the job of the separate Secure, SameSite, Domain, and Path attributes.
The most direct way to abuse a cross-site scripting flaw is to read the victim's session cookie and ship it to an attacker-controlled server, letting them replay the session and impersonate the user. HttpOnly removes that primitive: even code that successfully executes on the page cannot see the cookie value, so it cannot exfiltrate it by simple reads. That raises the bar meaningfully for session hijacking. It is important to be precise about the limit, though: HttpOnly stops the cookie from being read, not from being used. An injected script can still issue authenticated requests in the browser, riding the cookie the browser attaches automatically.
Set HttpOnly on every cookie that JavaScript has no legitimate reason to touch, especially session and auth tokens, and pair it with Secure and an appropriate SameSite value. Do not treat it as an anti-XSS control in itself: the real fix for injection is input handling, output encoding, and a strong Content Security Policy. HttpOnly limits the damage if those fail. Because an injected payload can still act within the session without ever reading the cookie, detecting the malicious script itself matters. cside analyses third-party script payloads through a Script method and can block anomalous behaviour in real time, closing the gap cookie flags leave behind.
No. HttpOnly stops a script from reading the cookie, but the injected script still runs with the user's privileges and can send authenticated requests, alter the page, capture keystrokes, or steal data from forms. HttpOnly reduces one consequence of XSS; it does not prevent the vulnerability or its other abuses.
Set it on any cookie JavaScript does not need, which covers most session and authentication cookies. The exception is a cookie your own client-side code must read, for example some CSRF-token or UI-state patterns. For those, keep the value non-sensitive and rely on other protections rather than dropping HttpOnly on the session cookie.
We answer client-side security questions every day. Bring yours.