Does HttpOnly stop XSS? Myth versus fact

No. HttpOnly keeps JavaScript from reading a cookie, which blocks one common theft route. It does not stop injected script from running, and that script can still send requests as the logged in user. Treat it as a mitigation, never as a fix for XSS.

What HttpOnly actually does

MDN describes it plainly: an HttpOnly cookie cannot be accessed through document.cookie. It is sent to the server and nowhere else in script. MDN says this helps mitigate XSS attacks. It does not call it a complete defence.

So with HttpOnly on your session cookie, a payload that tries to read the cookie and post it to the attacker gets nothing.

What an attacker can still do

Script that runs in your page runs with the user's privileges. Without ever seeing the cookie, it can:

• Call your API with fetch, and the browser attaches the cookie automatically.
• Change the page, for example by showing a fake login form to collect a password.
• Read anything the page shows, including personal data, and send it out.
• Read CSRF tokens in the page and submit state changing requests. OWASP's CSRF cheat sheet warns that XSS can defeat every CSRF mitigation.

The OWASP XSS prevention page says cookie attributes try to limit the impact of an XSS attack but do not prevent execution of malicious content.

Myth and fact pairs

• Myth: HttpOnly makes session hijacking impossible. Fact: it blocks cookie theft through script. The session can still be used in place through requests the script makes.
• Myth: If our cookies are HttpOnly we can skip output encoding. Fact: encoding by context is the primary control, as OWASP explains.
• Myth: HttpOnly stops the cookie from being sent to the wrong site. Fact: that is the job of Secure, SameSite, domain scoping and the __Host- prefix.

What to do instead

Keep HttpOnly on session cookies, along with Secure and a SameSite value. Then spend effort on the controls that stop injection:

1. Encode output for the exact context: HTML body, attribute, JavaScript, CSS or URL.
2. Avoid unsafe sinks such as innerHTML. Use textContent where you can.
3. Sanitize HTML only when users must author it, with a maintained library, as late as possible.
4. Add a Content Security Policy as a second layer. OWASP says it should not be the primary defence.
5. Consider Trusted Types to shut down whole classes of DOM XSS.

One more habit helps: test your own pages. Inject a harmless marker string into each input field in a staging copy and look at where it appears in the page source, so you know which context it lands in.

Quick check

Sources

• MDN: Using HTTP cookies
• OWASP Cross Site Scripting Prevention Cheat Sheet
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet

Last reviewed: 19 October 2026.