Contact

What is HttpOnly Cookie?

Definition

An HttpOnly cookie is a cookie that the server marks with the HttpOnly attribute in its Set-Cookie header, which tells the browser to hide it from JavaScript running on the page. It cannot be read through document.cookie, yet it is still sent with HTTP requests to its domain. On session cookies, it stops an XSS flaw from simply reading the session ID and sending it elsewhere.

Also known as: HttpOnly, HttpOnly flag, HttpOnly attribute

Published
Diagram of an HttpOnly cookie that is sent with HTTP requests but hidden from JavaScript, so XSS cannot steal the session

A cookie is normally reachable in two ways: in the Cookie header the browser sends with each request, and through document.cookie in page scripts. A cookie carrying a session ID rarely needs the second route; the server reads the ID and the front-end code never has to know it. The HttpOnly attribute shuts that route. The cookie keeps travelling with requests, but scripts cannot see it.

Set-Cookie: __Host-session=7c2e9f0b41; Path=/; Secure; HttpOnly; SameSite=Lax

Each part does its own job. Secure keeps the cookie on HTTPS connections, HttpOnly hides it from scripts, and SameSite limits whether it is attached to cross-site requests. The __Host- prefix makes the browser enforce extra rules: the cookie must be Secure, must not have a Domain attribute and must use Path=/, so it is only ever sent to the exact host that set it, never shared with subdomains.

What it buys you against XSS

When a page has an XSS flaw, the injected script runs inside that page with the user's privileges. If the session cookie is readable, a single line of script can send it to the attacker, who can then use the account from their own machine for as long as the session lives. HttpOnly blocks that direct theft.

Its limits are just as important, and often misunderstood:

  • It does not prevent XSS. A script that cannot read the cookie can still make requests on the user's behalf while the page is open, because the browser attaches HttpOnly cookies to fetch() calls too. The real fix is preventing XSS in the first place.
  • It does nothing for CSRF. Whether cookies go along with cross-site requests is governed by SameSite and anti-CSRF tokens, not by HttpOnly.
  • It is not secrecy or encryption. Users can see their own cookies in developer tools, and the value is stored as-is. Keep sensitive data out of cookies.

Only the server can set it

RFC 6265 tells browsers to ignore any cookie with the HttpOnly flag that arrives through a non-HTTP API such as JavaScript. An HttpOnly cookie is therefore always created by a Set-Cookie response header. In Express, for example:

res.cookie("__Host-session", sessionId, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/",
  maxAge: 1000 * 60 * 60 * 8 // 8 hours
});

Most frameworks' session layers ship with these settings, but teams that hand-roll authentication should check the defaults rather than assume them.

Single-page apps often debate where to keep tokens such as a JWT. Anything in localStorage is available to every script on the page, so one XSS flaw means the token is gone. An HttpOnly cookie removes that exposure but, because the browser sends it automatically, makes CSRF protection mandatory. For most web applications a short-lived session cookie set with HttpOnly, Secure and SameSite is the more defensible choice, with fewer moving parts.

Checking it in thirty seconds

The cookie list under the Application (Chrome) or Storage (Firefox) panel shows an HttpOnly column for every cookie. If typing document.cookie in the console prints your session cookie's value, the flag is missing.

Related terms

← Back to the glossary