Missing SameSite Cookie Attribute

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Cookie Security / Session Management
Typical Severity Medium
OWASP A01:2021 – Broken Access Control; A05:2021 – Security Misconfiguration
CWE CWE-1275 – Sensitive Cookie with Improper SameSite Attribute
Also known as SameSite cookie misconfiguration, CSRF via cookie, cross-site cookie leakage
Affected systems Any web application that issues session, authentication, or sensitive functional cookies
Relevant standard RFC 6265bis (draft-ietf-httpbis-rfc6265bis)

Overview

The SameSite cookie attribute, introduced in Google Chrome 51 (2016) and subsequently standardised in RFC 6265bis, instructs browsers whether to include a cookie when a request originates from a different site. When this attribute is not explicitly set—or is set to SameSite=None without a justified reason—the browser may attach the cookie to cross-origin requests initiated by third-party pages. This behaviour is the primary prerequisite for Cross-Site Request Forgery (CSRF) attacks and also contributes to cross-site information leakage.

Prior to 2020, the implicit browser default was to send cookies with all requests regardless of origin (equivalent to SameSite=None). Modern browsers (Chrome 80+, Firefox, Safari) now default to SameSite=Lax when the attribute is absent, partially mitigating the risk — but this browser-level default is not a substitute for explicit server-side configuration, as older browsers and non-standard user agents do not apply this heuristic.

How it works

The SameSite attribute accepts three values, each defining a different enforcement level:

  • Strict: The cookie is only sent when the request originates from the same site as the cookie's domain. No cross-site sending occurs under any circumstances.
  • Lax: The cookie is sent with same-site requests and with top-level navigations (e.g., clicking a link) that use safe HTTP methods (GET, HEAD). It is not sent with cross-site sub-resource requests (images, iframes, AJAX/fetch).
  • None: The cookie is sent with all requests, regardless of origin. Requires the Secure attribute to be set simultaneously; without it, modern browsers reject the cookie entirely.

When the attribute is missing and the browser falls back to Lax, state-changing GET endpoints remain exposed. When the browser is older or non-compliant and falls back to None-equivalent behaviour, all state-changing endpoints are exposed. An attacker can exploit this by embedding a forged request (form auto-submit, image tag, fetch call) in a page they control:

  1. Victim is authenticated on bank.example.com; a session cookie without SameSite is stored.
  2. Victim visits attacker-controlled evil.example.com.
  3. The malicious page silently issues a POST request to bank.example.com/transfer.
  4. The browser attaches the session cookie automatically, and the server processes the request as legitimate.

Beyond CSRF, missing SameSite also enables cross-site search attacks and timing side-channels where an attacker infers authentication state from cookie presence.

Business impact

A successful CSRF exploit enabled by a missing SameSite attribute allows an attacker to perform any action the victim can perform while authenticated — including changing account credentials or email addresses, initiating financial transfers, modifying configuration, or deleting data. The attacker requires no knowledge of the victim's credentials; only the victim's active session is needed.

Compliance implications include violations of OWASP ASVS (Level 1, requirement 3.4.3), PCI DSS requirements for session management, and GDPR obligations to protect personal data through appropriate technical measures. Organisations in regulated industries may face fines, audit findings, or contractual penalties following a breach attributable to this misconfiguration.

How to fix it

  1. Set SameSite=Lax as the baseline for all session and authentication cookies. This is the recommended default for most applications and prevents cookie transmission on cross-site sub-resource requests while preserving functionality for top-level navigations.
  2. Use SameSite=Strict for highly sensitive cookies (e.g., administrative sessions, payment flows) where breaking cross-site navigation links is acceptable.
  3. Avoid SameSite=None unless the cookie is explicitly required in a cross-site context (e.g., embedded widgets, OAuth flows). If None is necessary, always combine it with Secure and add additional CSRF defences such as the Synchronizer Token Pattern or the Double Submit Cookie pattern.
  4. Set the attribute server-side on every Set-Cookie response header, not relying on browser defaults. Example: Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
  5. Audit all cookies issued by first-party code and third-party libraries/frameworks. Many web frameworks offer global cookie configuration (e.g., SESSION_COOKIE_SAMESITE in Django, cookie.sameSite in Express-session, session.cookie.samesite in Spring Boot).
  6. Do not rely solely on browser defaults as a mitigation — older browsers, embedded WebViews, and non-standard clients may not apply the Lax default behaviour.
  7. Layer defences: Complement SameSite with CSRF tokens for all state-changing requests, the Origin/Referer header validation, and the HttpOnly and Secure flags on the same cookies.

References

Frequently asked questions

Modern browsers (Chrome 80+, Firefox, recent Safari) default to SameSite=Lax when the attribute is absent. However, older browsers and non-standard clients treat it as SameSite=None, sending the cookie with all cross-site requests. Relying on this browser-level default is not a substitute for explicit server-side configuration.

SameSite=Lax prevents cookie transmission on cross-site sub-resource requests (images, iframes, AJAX). However, it still allows cookies on top-level GET navigations, which means GET-based state-changing endpoints remain vulnerable. For complete CSRF protection, combine SameSite=Lax or Strict with CSRF tokens.

SameSite=None is only appropriate when a cookie must be sent in a legitimate cross-site context, such as third-party embedded widgets, cross-origin OAuth flows, or federated login scenarios. It must always be accompanied by the Secure attribute, and additional CSRF mitigations (e.g., CSRF tokens) should be applied.

They are complementary defences at different layers. Missing SameSite means the browser does not restrict which sites can trigger cookie-bearing requests. Missing CSRF tokens means the server does not verify that a request was intentionally initiated by the user. Best practice is to implement both independently.

At minimum, session cookies, authentication tokens, and any cookie whose presence or value affects server-side state or access decisions should have SameSite set. A broad policy of applying SameSite=Lax to all cookies is the safest and most maintainable approach.