When should teams prioritise HttpOnly cookies over local storage for JWTs?

Choosing HttpOnly cookies over local storage is really a session security decision

The main trade-off is where the JWT can be read. If a token is stored in local storage, any successful JavaScript execution can usually read and exfiltrate it. With HttpOnly cookies, the browser withholds the token from script access, which meaningfully changes the impact of XSS and token theft. That is why the choice is less about preference and more about attack surface.

HttpOnly cookies also fit better when the token is treated as a server-managed session credential rather than a portable bearer artifact. The server can pair that model with expiration, rotation, audience checks, and revocation logic. When those controls are in place, the cookie approach usually offers a safer default for browser-based apps that do not need script-side token handling.

By contrast, local storage is only attractive when the application genuinely needs the token in JavaScript, for example to attach it to non-cookie flows or to share it across browser contexts in a way cookies do not support cleanly. Even then, teams should assume that any XSS bug turns token access into token exposure, so the decision must be made with the threat model in mind.

When cookie transport becomes the better fit

HttpOnly cookies are usually the better choice when the app is a browser-based web application, the backend can enforce server-side session state, and the team can tolerate cookie-specific protections such as SameSite, path/domain scoping, secure transport, and CSRF defence. In that model, the browser automatically sends the credential, but the application must deliberately constrain where and when it is accepted.

This pattern is especially strong for apps where the token’s main job is browser session continuity, not client-side identity plumbing. It reduces the chance that a front-end bug, dependency compromise, or injected script can simply read the JWT value and replay it elsewhere. Token and Session Security Guide covers the practical controls that make that model work.

It is also a better fit when the team can keep the cookie narrowly scoped. A cookie set for a broad parent domain, with permissive paths or weak SameSite handling, can create cross-app exposure that undermines the benefit. The control works best when the browser is used as the transport, but the server still owns the trust decisions.

What makes the decision unsafe, and what practitioners should verify

The biggest mistake is treating HttpOnly as a complete fix. It blocks JavaScript reads, but it does not remove CSRF risk, session fixation risk, or poor revocation design. If the application cannot reject stolen or stale tokens quickly, a cookie-based session can still be abused after compromise.

Teams should also be careful when the JWT contains long-lived privilege, broad audience scope, or sensitive claims that are accepted across multiple services. In those cases, token theft becomes a high-value event whether the token lives in a cookie or storage. For browser apps that depend on JWT handling, Microsoft Storm-0558 key breach 2023 is a useful reminder that signing and validation failures can turn token trust into a systemic exposure.

When evaluating the storage choice, verify three things: the app can enforce anti-CSRF controls, the cookie scope is intentionally narrow, and the server can revoke or expire sessions in a way users experience quickly enough to matter. If any of those are missing, the security gain from HttpOnly may be smaller than it first appears.

Risk and Threat Considerations

Storing JWTs in local storage makes token theft easier for any attacker who can execute script in the page, steal a browser state, or abuse an injected dependency. HttpOnly cookies reduce that exposure, but they shift the main risk toward request forgery and session management weaknesses, especially when the app relies on ambient browser sending behaviour.

Failure mechanism: XSS or malicious script can read local storage directly, whereas HttpOnly cookies block that read path but still allow the browser to attach the token automatically to eligible requests. If CSRF controls, cookie scoping, and revocation are weak, an attacker can still use the session without ever seeing the raw token.

Impact: The wrong storage choice can widen the blast radius of a single client-side flaw from “page compromise” to “account compromise.” At that point, the decisive question is not only where the JWT sits, but whether the application can contain replay, cross-site abuse, and stale-session acceptance fast enough to limit misuse.

Practitioner Guidance

What to prioritise: Choose HttpOnly cookies first when the JWT is really functioning as a browser session credential and the backend can own revocation, scope, and CSRF protection. Choose local storage only when the application genuinely needs script-level access and you have accepted the extra exposure that comes with it.

What to verify: Confirm that the cookie is Secure, HttpOnly, and tightly scoped by domain and path, then verify that CSRF protection is present for state-changing requests. Also confirm that expiry and revocation are aligned with how quickly you need to invalidate a compromised session.

Practitioner takeaway: The safer default for browser sessions is usually HttpOnly cookies, but only when the server side is mature enough to enforce the controls that cookies make necessary.

Related resources from NHI Mgmt Group

• What do teams get wrong about storing sensitive application data in cookies, JWTs, local storage, or log files?
• How should security teams handle authentication data when choosing between cookies and local storage?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?