Skip to main content

Cookie SameSite.

Security Headers & TLS Config

Prevents cookies from being sent with cross-site requests — blocks CSRF attacks

What does this check test?

The `SameSite` attribute controls whether a cookie is sent with cross-site requests. It accepts three values: `Strict` (cookie is only sent in first-party context — never with cross-site requests), `Lax` (cookie is sent with top-level navigations like clicking a link, but not with cross-site POST requests or resource loads), and `None` (cookie is sent with all cross-site requests, but requires the `Secure` flag). Modern browsers default to `Lax` if SameSite is not explicitly set.

Why does it matter?

Cross-Site Request Forgery (CSRF) attacks exploit the fact that browsers automatically include cookies with every request to a domain, regardless of which site initiated the request. An attacker's page can submit a form to your banking site, and the browser will include the victim's session cookie, allowing unauthorized transactions. SameSite prevents this by ensuring cookies are not sent with requests originating from other sites. `Lax` blocks CSRF on POST requests while still allowing normal link navigation, making it the recommended default.

Who is affected?

All web applications that use cookie-based authentication should set SameSite on session cookies. Applications with state-changing operations (transfers, settings changes, data deletion) are especially at risk for CSRF. `Lax` is appropriate for most applications. `Strict` is recommended for highly sensitive operations like banking but may break legitimate cross-site navigation. `None` should only be used for cookies that intentionally need cross-site access (e.g., embedded widgets, SSO).

Where does this apply?

SameSite is set as an attribute in the `Set-Cookie` header alongside HttpOnly and Secure. Review all session and authentication cookies in your application. Check browser DevTools under Application > Cookies to see the SameSite value for each cookie. Also verify that any cookies set to `SameSite=None` also have the `Secure` flag, as browsers reject `None` without `Secure`.

How to fix it

Set SameSite when creating cookies.

Node.js / Express

js 
res.cookie('session', token, {
  sameSite: 'lax',
  secure: true,
  httpOnly: true
});

Django

python 
SESSION_COOKIE_SAMESITE = 'Lax'  # default is 'Lax'
CSRF_COOKIE_SAMESITE = 'Lax'

Flask

python 
app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'

Next.js

ts 
response.cookies.set('session', token, {
  sameSite: 'lax',
  secure: true,
  httpOnly: true
});

Spring Boot

java 
server.servlet.session.cookie.same-site=lax

the raw header

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

cookies that must work cross-site

Set-Cookie: widget_session=abc123; SameSite=None; Secure; HttpOnly; Path=/
Note that `SameSite=None` requires `Secure` — browsers will reject the cookie otherwise. If your application relies on CSRF tokens, SameSite provides defense-in-depth but should not replace token-based CSRF protection entirely.

References

AppVet checks Cookie SameSite automatically

Run a free security scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit
← All checks