How does the "Cookie security flags" check work?

Cookies can be secured with three attributes: "Secure" (sent only over HTTPS), "HttpOnly" (inaccessible via JavaScript, protects against XSS theft) and "SameSite" (protects against cross-site CSRF requests). These three flags are independent and cumulative.

Why does the "Cookie security flags" check matter?

A session cookie without these flags can be stolen by a malicious script (XSS) or sent to a third-party site without the user's knowledge. This is one of the most common forms of session hijacking. These attributes cost nothing to add.

Security Check n°22 / 120

Cookie security flags

Cookies can be secured with three attributes: "Secure" (sent only over HTTPS), "HttpOnly" (inaccessible via JavaScript, protects against XSS…

Analyse my site for free

← All checks

What is it?

Understanding "Cookie security flags"

Every cookie sent by a server via the Set-Cookie header can carry security attributes that control how the browser handles it: Secure (the cookie is only transmitted over an HTTPS connection), HttpOnly (the cookie is inaccessible from JavaScript, protecting it from theft by a malicious script) and SameSite (the cookie is only sent within the context of same-origin navigation, limiting cross-site attacks).

These three attributes are independent and can be combined. A session cookie with none of them still works but offers the minimal level of protection — exactly what an attacker hopes to find to facilitate a session theft.

❌ Cookie without flags

      Set-Cookie: session=abc123

      ↳ readable in JS, sent in plaintext, sent cross-site

✅ Secured cookie

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

How we check it

How TheSiteFuse checks "Cookie security flags"

TheSiteFuse retrieves the Set-Cookie headers from the homepage's HTTP response (handles servers sending several distinct Set-Cookie headers). For each cookie, it checks for the textual presence of the three attributes Secure, HttpOnly and SameSite (case-insensitive). If a site sets no cookies on its homepage, the check automatically passes (nothing to secure). Otherwise, every attribute missing on at least one cookie is listed in the result.

Risks if it fails

Why "Cookie security flags" matters

Session theft via XSS — without HttpOnly, a malicious script injected through an XSS flaw can read document.cookie and exfiltrate the session cookie to a third-party server, allowing full impersonation of the logged-in user.
Network interception — without Secure, a cookie can be transmitted in plaintext if a page is accidentally loaded over HTTP, exposing the session to anyone intercepting traffic on an unencrypted network (public Wi-Fi, for example).
Easier CSRF attacks — without SameSite, the browser still sends the cookie even on a request initiated from a third-party site, making cross-site request forgery (CSRF) attacks easier.

How to fix

Fix "Cookie security flags" step by step

Flask

# config.py
app.config.update(
    SESSION_COOKIE_SECURE=True,
    SESSION_COOKIE_HTTPONLY=True,
    SESSION_COOKIE_SAMESITE='Lax',
)

Manual cookie (any framework)

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

PHP

session_set_cookie_params([
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

Choosing the SameSite value: Strict offers maximum protection but can break some external navigation flows (a link from an email to a logged-in page); Lax (recommended default) allows normal cross-site navigation while blocking the most dangerous cross-site POST requests.

Learn more

Reference resource

To deepen your understanding of the technical concepts behind this check, see the dedicated Wikipedia article.

Wikipedia — Cookie security flags

Does your site pass this check?

Run the free full audit (120 checks) and instantly discover what needs fixing.

Previous No email in plain text Next Server TLS version