Securing Your Cookies: HTTPOnly Flag for Cookie Theft Defense

By CyberOne Security TeamThis article was written by members of the CyberOne Security Team, drawing on decades of combined experience in cloud and network security, penetration testing, threat intelligence, and advisory services.

What the HTTPOnly Flag Does

The HTTPOnly flag is a cookie attribute that instructs the browser to prevent JavaScript from accessing the cookie value through the document.cookie DOM API. A cookie set with HttpOnly=true is sent with every HTTP request to the server but is invisible to any JavaScript running on the page — including malicious scripts injected by an attacker.

This matters because session cookies are the primary target of Cross-Site Scripting (XSS) attacks. An attacker who can inject JavaScript into a page can use document.cookie to steal the session token and impersonate the authenticated user — even without knowing their password. HTTPOnly disrupts that specific attack by making the session cookie inaccessible to JavaScript entirely.

How to Set the HTTPOnly Flag

In PHP, the setcookie() function’s seventh argument controls HTTPOnly:

// HTTPOnly enabled — JavaScript cannot read this cookie
setcookie("sessionId", "abc123", time() + 86400, "/", null, true, true);

// HTTPOnly disabled — JavaScript CAN read this cookie
setcookie("trackingId", "xyz789", time() + 86400, "/", null, false, false);

In JavaScript (Node.js / Express):

res.cookie('sessionId', token, {
  httpOnly: true,
  secure: true,       // HTTPS only
  sameSite: 'Strict'  // CSRF mitigation
});

In an HTTP response header directly:

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Strict

HTTPOnly in a Penetration Test

When CyberOne performs application security assessments, missing HTTPOnly flags on session cookies are a consistent finding — particularly in applications built on older frameworks or where cookie configuration was never explicitly reviewed. The finding is typically rated medium severity on its own, but it becomes a critical risk when paired with an XSS vulnerability in the same application: the XSS provides the injection point, and the missing HTTPOnly flag makes the session cookie the payload.

Testing for the flag during a penetration test is straightforward: browser developer tools show every cookie set by the application and which attributes are present. A session cookie without HTTPOnly is an immediately visible misconfiguration.

What HTTPOnly Doesn’t Protect Against

HTTPOnly is a single control, not a complete cookie security posture. Attackers have other approaches that bypass it:

Network interception: If the cookie is sent over HTTP instead of HTTPS, an attacker on the same network can capture it via packet inspection. HTTPOnly does nothing about this — the Secure attribute (which restricts the cookie to HTTPS connections) is the control that addresses network transmission risk.

CSRF attacks: HTTPOnly doesn’t prevent Cross-Site Request Forgery. An attacker can trick an authenticated user’s browser into making requests that include the session cookie, even if JavaScript can’t read the cookie value. The SameSite attribute is the primary CSRF mitigation for cookies.

Subdomain attacks: Without the Domain attribute configured correctly, cookies set on one subdomain may be accessible from another. An XSS vulnerability on a low-security subdomain (a marketing site, a partner portal) can be used to access cookies from the main application if domain scoping is wrong.

JavaScript-dependent functionality: Some cookies legitimately need to be accessible to JavaScript — analytics tokens, UI preferences, feature flags. These can’t have HTTPOnly set without breaking application functionality. That’s fine, but session cookies and authentication tokens should never be in this category.

The Secure Cookie Attribute Combination

Cookie security is a combination of attributes. A properly configured session cookie looks like this:

Set-Cookie: sessionId=abc123;
  Path=/;
  HttpOnly;          /* No JavaScript access */
  Secure;            /* HTTPS only */
  SameSite=Strict;   /* No cross-site requests */
  Max-Age=3600       /* Reasonable expiry */

HTTPOnly alone is not sufficient — a session cookie without Secure is still exposed to network interception on HTTP connections. All three attributes (HTTPOnly, Secure, SameSite) should be standard on session and authentication cookies. CyberOne’s application security assessments verify all three attributes across all cookies that contain sensitive values.

Content Security Policy as a Complement

HTTPOnly closes the cookie access vector for XSS. Content Security Policy (CSP) reduces the XSS risk itself by restricting which scripts can execute on a page. A strict CSP that prevents inline script execution and limits script sources to trusted domains makes XSS payloads significantly harder to land — even if an injection point exists, the browser may refuse to execute the injected script.

CyberOne implements CSP as part of application hardening engagements. The interaction between CSP and HTTPOnly is the key point: HTTPOnly handles “if XSS succeeds, cookie is still protected”; CSP handles “make XSS less likely to succeed in the first place.” Both controls together represent the appropriate defense-in-depth posture for session security.