Cookie without HttpOnly flag

Scan.now parses the Set-Cookie headers on the response to / and fails this check for any cookie without the HttpOnly attribute. Session and authentication cookies are highlighted (see cookie-secure-flag for the name patterns). A small number of cookies are designed to be read by script, most commonly the double-submit anti-CSRF token that Angular reads from XSRF-TOKEN and Django's csrftoken when CSRF_COOKIE_HTTPONLY is left at its default; these are listed as expected exceptions rather than failures. Scan.now only inspects headers; it does not execute page script or attempt to read cookies. As with the other cookie checks, only the anonymous response is visible, so review the cookies your application sets after login as well.

Cross-site scripting is the obvious route: an injected script calls document.cookie and posts the session identifier to an attacker's server, who then uses it from their own browser for as long as the session lives. HttpOnly removes the cookie from the script-visible set, so the same XSS cannot steal the session. That is a real but partial defence: the injected script can still act as the user from inside the page, submitting forms and reading responses, but it cannot persist access beyond the tab or reuse it elsewhere, and most real-world XSS payloads are simple cookie grabbers. The risk is not limited to XSS in your own code. Every third-party script on the page (analytics, chat widgets, tag managers) runs with the same access, and a compromised one, as in the 2024 polyfill.io incident, reads whatever cookies are not HttpOnly. The XSS guide and cookie flags guide give the wider picture.

Mark every cookie HttpOnly unless a script genuinely needs to read it:

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

PHP (php.ini):

session.cookie_httponly = 1

Express with express-session sets httpOnly: true by default; when setting cookies by hand:

res.cookie('session', token, { httpOnly: true, secure: true, sameSite: 'lax' });

Django: SESSION_COOKIE_HTTPONLY = True is the default; check that it has not been overridden. Spring Boot: server.servlet.session.cookie.http-only=true. ASP.NET Core: options.Cookie.HttpOnly = true in the cookie authentication options. When the application cannot be changed, add the attribute at the proxy. nginx 1.19.3+:

proxy_cookie_flags ~ httponly secure;

Apache: Header edit Set-Cookie ^(.*)$ "$1; HttpOnly". If a front-end framework needs a value that currently lives in a cookie, expose it through a meta tag or an API response instead of dropping HttpOnly from the session cookie.