Finding: Cookie Missing SameSite Attribute
A cookie set by this site is missing the SameSite attribute, so the browser will send it even on requests that originate from another site.
Last updated August 11, 2026.
What it means
The SameSite attribute on a Set-Cookie header controls whether the browser attaches that cookie to requests that originate from a different site — for example a form on attacker.example that submits to your domain, or an image tag that triggers a request to it. Without SameSite, older browser defaults send the cookie along regardless of where the request came from. This finding is scoped to that flag alone: it says nothing about whether the same cookie is also missing Secure or HttpOnly, which are reported as their own separate findings.
Why it matters
This is the mechanism behind CSRF (cross-site request forgery): another site can cause a signed-in visitor's browser to make a request to yours — submit a form, trigger a state-changing action — carrying their real session cookie, without the visitor meaning to or even noticing. The server has no way to tell that request apart from one the visitor made on purpose, because the cookie looks identical either way. SameSite closes that gap by telling the browser not to attach the cookie to cross-site requests in the first place.
What Nivaronix checks
Nivaronix makes a live request to the domain and inspects each Set-Cookie header in the response, parsing its attributes. This finding fires once per cookie found without a SameSite attribute. This is a configuration check against the live response — not a vulnerability scan, and it does not attempt to perform any cross-site request.
Example evidence (illustrative — not live scan data)
Missing SameSite:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly
Fixed:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
How to fix it
Set SameSite=Lax — a safe default for most sites, since it still allows the cookie on top-level navigation (a visitor clicking a link into your site) while blocking it on background cross-site requests — or SameSite=Strictfor session/auth cookies that don't need to survive arriving from an external link. Use SameSite=None; Secure only when the cookie genuinely needs to be sent cross-site, such as for an embedded widget your own site serves on other domains; None requires Secure to be set alongside it, or browsers will reject the cookie outright.
Express (Node.js)
res.cookie("session", token, {
httpOnly: true,
secure: true,
sameSite: "lax",
});Django
# settings.py SESSION_COOKIE_SAMESITE = "Lax" CSRF_COOKIE_SAMESITE = "Lax"
Rails
# config/environments/production.rb Rails.application.config.session_store :cookie_store, same_site: :lax
Raw header
Set-Cookie: name=value; Secure; HttpOnly; SameSite=Lax
How to verify the fix
Open your browser's DevTools → Application (Chrome) or Storage (Firefox) → Cookies, select the cookie, and confirm the SameSite column reads Lax or Strict (or None only alongside Secure). Or re-run the website security scanner and confirm this finding no longer appears.