Set secure cookie flags: HttpOnly, Secure, and SameSite

20 min Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

Cookies that store session identifiers or other sensitive data need explicit security flags — without them, a cookie can be read by client-side scripts (including an injected malicious one), sent over an unencrypted connection, or leaked to a completely different site.

Cookies without HttpOnly can be stolen by JavaScript (XSS attacks). Cookies without Secure are sent over HTTP. Cookies without SameSite are vulnerable to CSRF attacks. These three flags are basic cookie hygiene.

The full picture

Secure cookie flags address genuine, specific vulnerabilities in how cookies — the small data pieces websites use to maintain session state and other information — can be intercepted or misused if not properly configured, with each of the three flags addressing a distinct, real risk category.

The Secure flag ensures a cookie is only ever transmitted over encrypted HTTPS connections, never over plain HTTP — without this flag, a cookie could potentially be transmitted unencrypted if any part of a session somehow occurs over HTTP, exposing potentially sensitive session information to network-level interception during that unencrypted transmission.

The HttpOnly flag prevents client-side JavaScript from accessing a cookie's value at all, closing off a specific, genuine attack vector where a successful cross-site scripting attack could otherwise read and exfiltrate session cookies directly through malicious script execution — this flag ensures that even if such a script somehow executes on your page, it cannot access these specifically protected cookies.

The SameSite flag addresses cross-site request forgery risk by controlling whether a cookie gets sent along with requests originating from other sites — proper configuration here prevents a malicious site from being able to trigger authenticated actions on your site using a visitor's existing session cookie, a genuine and well-documented attack pattern this specific flag directly mitigates.

How to fix it

1

Add the HttpOnly flag

Prevents JavaScript from reading the cookie at all — the single most effective defense against session-stealing via XSS.
2

Add the Secure flag

Ensures the cookie is only ever sent over HTTPS, never accidentally over a plain HTTP connection.
3

Set SameSite appropriately

SameSite=Lax (or Strict for the most sensitive cookies) stops the cookie being sent along with cross-site requests, closing off a class of CSRF attacks.
4

Apply this to every cookie carrying meaningful data

Session tokens, auth tokens, and CSRF tokens specifically — not necessarily every single cookie your site sets (e.g. pure UI preference cookies matter less).

Common mistakes

SameSite=Strict can break legitimate cross-site flows like SSO redirects or payment gateway callbacks — test carefully, or use Lax where Strict causes problems.

How you'll know it's done

Session and auth cookies all carry HttpOnly, Secure, and an appropriate SameSite value.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →