SameSite

Overview

The SameSite cookie attribute is a modern, browser-enforced defense that limits when cookies are sent on cross-site requests — directly undercutting CSRF's core mechanism. This lesson explains SameSite and its role.

Learning objectives

• Explain what the SameSite cookie attribute does.
• Describe the Strict, Lax, and None values.
• Understand SameSite as part of layered CSRF defense.

Core concept

SameSite is a cookie attribute controlling whether a cookie is sent on cross-site requests:

• Strict — the cookie is not sent on any cross-site request (strongest, but can affect legitimate cross-site navigation/UX).
• Lax — the cookie is sent on top-level navigations using safe methods (like clicking a link) but not on cross-site subrequests/form posts (a balanced default).
• None — the cookie is sent on all cross-site requests (requires Secure); used when cross-site cookie sending is genuinely needed.

By restricting cross-site cookie sending, SameSite blunts CSRF, which depends on the cookie being auto-sent from another site.

How it works

CSRF relies on the browser attaching the session cookie to a state-changing request triggered by another site. With SameSite=Lax or Strict, the browser withholds the cookie on those cross-site requests, so the forged request arrives without the session and is not authenticated — the attack fails. Modern browsers default cookies to Lax when SameSite is unspecified, providing baseline protection. SameSite is powerful but should be treated as one layer: edge cases, older browsers, and certain request types mean it is best combined with anti-CSRF tokens.

Practical example

A session cookie set with SameSite=Lax is not sent on a cross-site form submission from an attacker's page. So even though the malicious page triggers a state-changing request to the target site, the browser omits the session cookie, and the site treats the request as unauthenticated — the CSRF fails. Setting the session cookie HttpOnly; Secure; SameSite=Lax thus contributes to both session protection and CSRF defense, layered with anti-CSRF tokens for robustness.

Cybersecurity relevance

SameSite has significantly reduced CSRF exposure across the web and is a recommended cookie setting. However, relying on it alone is discouraged because of exceptions (some navigations under Lax, SameSite=None cases, older clients). Best practice combines SameSite cookies with anti-CSRF tokens for defense in depth. Testers check the SameSite attribute on session cookies and whether token protection is also present; defenders set appropriate SameSite values and keep token protection for state-changing actions.

Common mistakes

• Relying on SameSite alone without anti-CSRF tokens, ignoring its exceptions.
• Using SameSite=None without need (and without Secure), removing the protection.
• Assuming default behavior is enough across all browsers and request types.

Key takeaways

• SameSite controls whether cookies are sent on cross-site requests: Strict (never cross-site), Lax (safe top-level navigations only — a balanced default), None (always, requires Secure).
• Lax/Strict blunt CSRF by withholding the session cookie on cross-site state-changing requests, so forged requests are unauthenticated.
• SameSite is a strong layer but has exceptions; combine it with anti-CSRF tokens for robust, defense-in-depth CSRF protection.

Check your understanding

• How does SameSite=Lax or Strict undercut a CSRF attack?
• Why is it recommended to combine SameSite cookies with anti-CSRF tokens rather than relying on SameSite alone?