Cookie can be read by JavaScript

MediumConfirmedQuick winweb.cookies.no-httponly

What this check looks for

This cookie has no HttpOnly flag, so any script running on the page can read it — including a script that was injected.

Why it matters

HttpOnly is the control that stops a cross-site scripting bug turning into stolen sessions. Without it, one injected script anywhere on the site can read the cookie and send it elsewhere.

When the check passes, your report says: “The cookie is marked HttpOnly, so page scripts cannot read it”.

What it costs your score

When this check fails it removes 10 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.cookies family ceiling of 30 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: warn
Deduction: 10 points
Family cap: web-security.cookies · 30
Category: Web security
Module: Web cookies
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Add HttpOnly to any cookie a script does not have to read.

It is what stops an injected script from stealing the session.

Add HttpOnly where the cookie is created.
If a script genuinely needs a value, split it: an HttpOnly session cookie plus a separate readable one.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i '^set-cookie:'

The configuration to publish

Set-Cookie: {{cookie}}=...; Secure; HttpOnly; SameSite=Lax; Path=/

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# Only for a cookie from an upstream you cannot change. Fix it in the application first.
proxy_cookie_flags ~ secure httponly samesite=lax;

Apache

<IfModule mod_headers.c>
	# Workaround for a cookie from an upstream you cannot change.
	Header always edit Set-Cookie ^((?!.*;\s*Secure).*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Caddy

header {
	+Set-Cookie "{http.response.header.Set-Cookie}; Secure; HttpOnly"
}

Express

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

Requires nginx 1.19.3 or later. This rewrites cookies passing through the proxy; it cannot help for a cookie the browser receives some other way.
Shown because the response identified Apache. It is a last resort: set the attributes where the cookie is created. Put it in the virtual host — .htaccess runs too late to edit a header the proxy module has already emitted.
Also a workaround; prefer setting the attributes in the application.

Technical detail

‹cookie› was set without HttpOnly. ‹detail›

Some cookies are legitimately read by scripts — a CSRF token double-submit value, a UI preference — so this is a warning rather than a failure, and the confidence is lowered when the cookie's name does not suggest a session. If a script does need the value, keep the session cookie HttpOnly and put the script-readable part in a separate cookie.