What is an example of an HttpOnly cookie in practice?

What an HttpOnly cookie looks like in a real browser flow

A practical example is a website session cookie set by the server after login, such as a session identifier stored in the browser with the HttpOnly attribute. The browser sends it automatically on later requests, but JavaScript running on the page cannot read it. That makes it a common control for reducing cookie theft from script-based attacks.

In practice, the value is usually not something a user or developer should inspect in client-side code. Instead, it should behave like an opaque token that only the browser and server understand. The security benefit depends on the cookie being used for a sensitive purpose, such as maintaining an authenticated session, rather than for a low-risk preference value.

Why HttpOnly is used with session cookies, not as a complete defense

HttpOnly is most useful when a cookie carries an authenticated session or other secret the application must protect from client-side exposure. It helps limit one common XSS outcome, direct JavaScript access to the cookie value. NHIMG’s Security Headers Guide also covers related cookie attributes and transport protections that need to be used together.

That protection is partial, not absolute. An attacker who can run script in the page may still act as the user inside that browser session, trigger requests, or abuse any accessible in-page actions. HttpOnly reduces theft of the cookie value itself, but it does not remove the underlying XSS problem or replace secure session handling.

What a secure implementation usually pairs with HttpOnly

For a session cookie to be defensible in production, it should be paired with secure transport, appropriate cookie scope, and short-lived sessions. Secure delivery prevents interception in transit, while careful lifetime management limits the value of a stolen or replayed session. The cookie should also be designed so that a new login or privilege change invalidates old session state.

When teams review a real implementation, they should verify that the cookie is only sent where needed, not exposed to client-side code, and not left valid far longer than the business risk justifies. If the application also relies on anti-CSRF defenses, those should be evaluated separately because HttpOnly does not stop cross-site request abuse on its own.

Risk and Threat Considerations

HttpOnly reduces the chance that a script injection issue turns directly into cookie theft, but it does not make a session safe if the application is otherwise vulnerable. The main threat is that attackers use XSS to impersonate the user from inside the live browser session, or combine stolen session state with fixation and replay opportunities.

Failure mechanism: If an attacker can execute script in the application, HttpOnly blocks direct cookie reads but does not stop the attacker from using the authenticated browser context, sending forged requests, or exploiting weak session lifecycle controls.

Impact: A compromised session can expose account data, permit unauthorized actions, and extend the blast radius if the session remains valid too long or survives privilege changes.

Practitioner Guidance

What to verify: Confirm that sensitive cookies are marked HttpOnly in the actual response headers, that they are also constrained with secure transport, and that session invalidation works after logout, password change, or privilege elevation. If the cookie can still be read in browser script, the control is not correctly implemented.

Decision rule: Treat HttpOnly as a session-hardening measure, not a substitute for XSS prevention or session lifecycle design. If the cookie protects an authenticated session, prioritize short validity, replay resistance, and server-side invalidation before relying on any client-side assumption.

Practitioner takeaway: The value of HttpOnly is that it narrows one theft path, but the real security outcome depends on whether the session behind the cookie is also tightly scoped, short-lived, and revocable.

Related resources from NHI Mgmt Group

• What is an example of third-party cookie deprecation in practice?
• What is an example of cookie syncing in practice?
• What is an example of a Secure cookie flag in practice?
• What are the signs that a cookie compliance programme is failing in practice?