Vigil
All articles
SecurityAug 12, 2026 · 6 min read

Cookie flags that matter: Secure, HttpOnly, SameSite (and scope)

Cookies carry your users' sessions. Four small attributes decide whether that session can be stolen over plain HTTP, read by injected JavaScript, or ridden by another site. Vigil flagged a cookie missing one of them — here is why each matters.

NB
Nebojsa B.
CTO, Lilly021

Vigil fetches your page over HTTPS and inspects the Set-Cookie headers it sends back — the attribute flags only, never the cookie values. The flags below are what stand between a session cookie and an attacker; each finding names the cookie and the missing attribute.

Secure — HTTPS only

A cookie without the Secure attribute is sent over plain HTTP too. That means one downgraded or intercepted request can hand an attacker the session — over HTTPS this is the highest-severity cookie finding Vigil raises, and it scores it as a fail.

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

HttpOnly — invisible to JavaScript

HttpOnly stops document.cookie from reading the value, so a cross-site scripting bug can't simply exfiltrate the session token. Vigil applies this check to cookies that look like session or auth cookies by name — those are the ones worth stealing.

SameSite — cross-site request defence

SameSite tells the browser when to attach the cookie to requests coming from other sites, which is the core defence against cross-site request forgery (CSRF). Vigil raises a finding when there is no SameSite attribute at all, and a separate one for SameSite=None sent without Secure — an invalid combination modern browsers reject outright.

# a good default for a first-party session cookie
Set-Cookie: session=…; Secure; HttpOnly; SameSite=Lax

# only when the cookie MUST cross sites (embeds, SSO) — Secure is then mandatory
Set-Cookie: session=…; Secure; HttpOnly; SameSite=None

Scope — keep Domain and Path tight

A cookie scoped to a parent domain (a leading dot, .example.com) or a broad path is sent to every subdomain and section of the site — including ones you don't control as tightly. Vigil flags an overly broad Domain so you can pin the cookie to the exact host and the narrowest path that needs it.

// Node/Express
res.cookie("session", token, {
  secure: true,
  httpOnly: true,
  sameSite: "lax",
  path: "/",        // as narrow as the app allows
  // omit `domain` to scope to the exact host
});
# PHP — session cookie params
session_set_cookie_params([
  'secure'   => true,
  'httponly' => true,
  'samesite' => 'Lax',
  'path'     => '/',
]);
Secure, HttpOnly and a sensible SameSite are three words of config that decide whether an XSS bug or a coffee-shop network costs you a session.— the RD-17 design note

Set the flags on your session and auth cookies first, then re-run the check. Vigil re-reads the Set-Cookie attributes and clears each finding as the flags appear — the cookie values are never read, stored or shown.

Can’t fix it yourself? We’ll do it for you.

Our team can apply this fix on your site and verify it with Vigil. Already monitoring this site with Vigil? Open the failing check and hit “Request a fix” — we’ll get the exact problem and URL. Otherwise, get in touch.

Watching client sites the hard way? Try Vigil free →
More articles