What Is the SameSite Cookie Attribute and How Does It Prevent CSRF?
Learn how the SameSite cookie attribute (Strict, Lax, None) works and how it prevents cross-site request forgery attacks.
Expected Interview Answer
SameSite is a cookie attribute that tells the browser whether to include the cookie on requests originating from a different site than the one that set it, and setting it to Strict or Lax is a primary defense against cross-site request forgery.
A CSRF attack works by getting a victim’s browser to submit a request to a site the victim is already authenticated to, relying on the browser automatically attaching the victim’s session cookie to that cross-site request. SameSite=Strict tells the browser to never send the cookie on any cross-site request, even top-level navigation from a link on another site, which is the strongest protection but can break legitimate cross-site flows like arriving from an external link while still logged in. SameSite=Lax, the modern browser default, allows the cookie on top-level GET navigations from other sites but blocks it on cross-site subrequests like form POSTs, image loads, or fetch calls triggered by another origin, which stops the classic forged-form CSRF pattern while keeping normal link-clicking usable. SameSite=None disables the restriction entirely and requires Secure, needed for legitimate cross-site use cases like third-party embeds or payment iframes, but it reintroduces the CSRF risk that SameSite was designed to close, so it should be paired with other defenses like CSRF tokens.
- Blocks the browser from auto-attaching session cookies to cross-site requests
- Stops the classic forged cross-site form POST CSRF pattern by default
- Lax mode preserves normal cross-site link navigation while blocking subrequests
- Works as defense-in-depth alongside CSRF tokens and double-submit patterns
AI Mentor Explanation
SameSite is like a stadium gate that only honors your season pass if you walked in directly from the stadium’s own ticket office, not if some stranger’s flyer redirected you through a side gate. Strict mode refuses the pass on any entry that did not start at the stadium itself. Lax mode still lets you in if you clicked a link from outside and arrived at the main gate, but refuses the pass for any sneaky side-door request triggered by another site’s page. That selective honoring of the pass based on where the request truly originated is exactly what SameSite enforces for cookies.
Step-by-Step Explanation
Step 1
Server sets SameSite on the cookie
Set-Cookie includes SameSite=Strict, Lax, or None (with Secure) depending on the use case.
Step 2
Browser tags the cookie
The browser remembers the restriction alongside the cookie value.
Step 3
Request origin is evaluated
On each outgoing request, the browser compares the target site to the page that initiated the request.
Step 4
Cookie attached or withheld
Based on the SameSite policy and request type (navigation vs subrequest), the cookie is included or dropped.
What Interviewer Expects
- Clear explanation of how CSRF exploits automatic cookie attachment
- Correct distinction between Strict, Lax, and None behavior
- Awareness that Lax is the modern browser default
- Understanding that SameSite is defense-in-depth, not a complete CSRF solution alone
Common Mistakes
- Claiming SameSite alone eliminates all CSRF risk in every scenario
- Confusing SameSite with CORS, which is a different, unrelated mechanism
- Forgetting SameSite=None requires the Secure attribute
- Not knowing Lax still allows top-level GET navigation cookies through
Best Answer (HR Friendly)
“SameSite tells the browser when it’s okay to send your login cookie along with a request. If the request comes from some other, unrelated website trying to trick your browser into acting on your behalf, SameSite can block the cookie from being sent, which stops a classic attack called CSRF. Setting it to Strict or Lax is a simple, effective way to protect logged-in users.”
Code Example
app.post('/login', async (req, res) => {
const sessionId = await createSession(req.body)
res.cookie('sessionId', sessionId, {
httpOnly: true,
secure: true,
sameSite: 'lax', // blocks cross-site POSTs, allows link navigation
})
res.json({ ok: true })
})Follow-up Questions
- When would you need SameSite=None instead of Lax or Strict?
- How do CSRF tokens complement SameSite protection?
- What is the difference between CSRF and CORS?
- How does SameSite=Strict affect a user clicking an external link into your logged-in app?
MCQ Practice
1. What attack does SameSite primarily help prevent?
SameSite restricts automatic cookie attachment on cross-site requests, blocking forged-request attacks.
2. What is the modern browser default for SameSite when unspecified?
Modern browsers default unspecified cookies to Lax behavior.
3. What additional attribute does SameSite=None require?
Browsers reject SameSite=None cookies that are not also marked Secure.
Flash Cards
What does SameSite=Strict do? — Never sends the cookie on any cross-site-triggered request.
What does SameSite=Lax do? — Allows top-level cross-site navigation but blocks cross-site subrequests like form POSTs.
What does SameSite=None require? — The Secure attribute, since it disables the cross-site restriction entirely.
What attack does SameSite target? — Cross-site request forgery (CSRF).