What Happens When a Cookie Lacks a SameSite Attribute?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Modern browsers treat cookies without a SameSite attribute as SameSite=Lax.
• Legacy browsers may still send such cookies on every request, exposing you to CSRF.
• Explicitly set SameSite=Lax or Strict on all first - party cookies; use SameSite=None; Secure only for genuine cross - site use cases.
• Verify the attribute with a simple curl command or browser dev tools.

Why does a missing SameSite attribute matter?

A missing SameSite attribute no longer means the cookie is unrestricted; browsers now apply a Lax default, which blocks most cross - site sub - resource requests. This change directly impacts CSRF defenses and how your session persists across navigation.

How do modern browsers handle cookies without SameSite?

All browsers released after 2020 (Chrome 80+, Edge 80+, Firefox 69+, Safari 13+) interpret the absence of the attribute as SameSite=Lax. The cookie is sent on same - site requests and on top - level cross - site navigations that use safe HTTP methods (GET, HEAD, OPTIONS, TRACE). It is omitted from cross - site fetches, iframes, XHR/fetch calls, and POST forms.

Which browsers still send cookies unrestricted?

Older browsers that pre - date the Lax - by - default change (e.g., Chrome < 80, Firefox < 69) treat a missing attribute as "no restriction" and include the cookie on every request, which can be abused for CSRF attacks.

What is the security impact of the Lax default?

Because the default is Lax, most cross - site POST - based CSRF attacks are blocked while users can still follow external links and stay logged in. However, if an attacker can trigger a top - level navigation (e.g., a link click), the cookie will be sent and the session may be hijacked if other defenses are missing.

How to check whether your cookies have SameSite set?

# Use curl to view Set - Cookie headers
curl -I https://example.com | grep Set-Cookie

In Chrome DevTools, open the Application tab, expand Cookies, and look for the SameSite column. If the column shows "Lax" for a cookie that you did not set, the browser applied the default.

How to add the attribute correctly?

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

• Use SameSite=Strict for the highest protection when the cookie never needs to be sent to another site.
• Use SameSite=None; Secure only for third - party widgets, SSO, or embeds that require the cookie in all contexts.
• Always include Secure when using SameSite=None to satisfy browser enforcement.

Comparison of cookie behavior by browser version

Should I rely on the default Lax behavior?

No. Relying on the default makes your intent unclear and can cause inconsistent behavior in older browsers. Explicitly setting the attribute removes ambiguity and satisfies security scanners that flag missing SameSite as a low - severity issue.

Steps to remediate missing SameSite attributes

1. Identify all Set - Cookie headers without a SameSite value using curl or browser dev tools.
2. Classify each cookie: first - party session cookies, third - party tokens, or static preferences.
3. Update server - side cookie generation code to include SameSite=Lax for first - party cookies.
4. For any cookie that must be sent in cross - site contexts, add SameSite=None; Secure.
5. Deploy the changes and re - run a security scan to verify the issue is resolved.

When is SameSite=None; Secure appropriate?

Use this combination only when the cookie is required by a third - party service that operates on a different domain, such as an SSO provider, payment gateway, or analytics widget. Ensure the cookie is transmitted over HTTPS to satisfy the Secure requirement.

What about cookies used in APIs?

API authentication cookies should almost always be SameSite=Strict or Lax to prevent them from being sent with cross - site requests. If an API is accessed from a JavaScript client on a different domain, prefer token - based authentication (e.g., Bearer tokens) over cookies.

Final recommendation

Always set the SameSite attribute explicitly. Choose Lax for typical session cookies, Strict for high - security contexts, and None; Secure only when cross - site usage is required. Verify the change across browsers and re - scan with Decloak to ensure no missing flags remain.