Headers

SameSite + Secure cookies: the two attributes every session cookie needs.

Published 2026-05-03 · Last updated 2026-05-03 · Vantyris editorial

Every session cookie your site sets needs two attributes set correctly: Secure (only sent over HTTPS) and SameSite (only sent on first-party requests). Without Secure, an attacker on the same network as your visitor can steal the session cookie. Without SameSite, a malicious third-party site can use it to impersonate your user in a cross-site request forgery (CSRF) attack. Modern browsers default to SameSite=Lax if you don't set it, which helps. Setting it explicitly lets you pick the right value for each type of cookie, and leaves a clear audit trail.

What this means for your business

Without Secure, your session cookie can be sent over a plain HTTP connection (if any subdomain still serves HTTP). Anyone on the visitor's network can read it and replay it to log in as the visitor.
Without SameSite, a malicious site the visitor opens in another tab can trigger a request to your site (via an image tag, a form submission, or a fetch call), and the browser attaches your session cookie automatically. The malicious site can effectively do anything your visitor could.
SameSite=Lax (the modern default) attaches the cookie on top-level navigations (clicking a link) but not on cross-site embedded requests (iframes, forms). SameSite=Strict attaches it only on same-site navigations. SameSite=None is required for cookies sent in third-party contexts (embedded widgets, for example), and it requires Secure too.

How to fix

Audit every Set-Cookie response from your application. Add Secure; SameSite=Lax (or Strict for session cookies) to each one. For OAuth + payment-redirect flows that need cross-site cookies, use SameSite=None; Secure explicitly.

Audit your current Set-Cookie responses. Open Chrome DevTools → Application → Cookies and list every cookie your site sets. Click each one and check the Secure and SameSite columns. An empty value means the browser is using its default. An explicit one means someone made a choice.
Update your framework's cookie defaults. Node.js Express: app.use(session({ cookie: { secure: true, sameSite: 'lax' } })). Rails: Rails.application.config.session_store :cookie_store, secure: true, same_site: :lax. Next.js (cookies via headers): pass secure: true, sameSite: 'lax' to every cookies().set(...) call.
Handle the cross-site exceptions explicitly. For cookies that genuinely need to work cross-site (third-party widget consent, embedded checkout flows), set SameSite=None; Secure. Browsers reject None without Secure. Don't use None unless you've thought it through. Keep Lax as the default.
Verify in DevTools after deploy. Reload your site and re-check Application → Cookies. Each cookie should now show explicit values. If any are missing, that cookie is being set somewhere you didn't update (often a third-party library).

Owner: Your developer. · Time: 30-60 minutes for a typical app with 3-5 cookies.

Common gotchas

Secure requires HTTPS. If your local dev environment runs on HTTP, the flag stops the cookie being set during development. Most frameworks have an is_production toggle that applies the flag in production only.
SameSite=Strict blocks the cookie on the first click from an email or a social share, so users land on your site logged out. Most sites prefer SameSite=Lax for session cookies and keep Strict for high-risk flows (e.g., the admin panel).
Older browsers (pre-2017) don't understand SameSite and treat it as missing. Their market share is negligible today. Ignore them.
Some payment SDKs (Stripe Checkout, embedded PayPal) require third-party cookies and break under SameSite=Lax. Use SameSite=None; Secure for those specific cookies. Leave the others alone.

How to verify the fix

A Vantyris verified scan checks every Set-Cookie response and flags any missing Secure or SameSite. In DevTools, the Application → Cookies tab shows the attributes explicitly.

Cyber Essentials alignment

This finding informs the following Cyber Essentials control areas (the UK government's baseline scheme, a sound checklist in any country):

A2. Secure configuration: devices and services hardened against the weaknesses they ship with by default.

Vantyris is not a CE certifying body. The mapping above is informational.

Common follow-up questions

Do these attributes prevent XSS attacks?

Partly. They prevent COOKIE THEFT via XSS if you also set HttpOnly (which stops JavaScript reading the cookie). XSS that doesn't need to read the cookie (e.g., performing actions while the user is logged in) is still possible. CSP is the main XSS defence.

What if I use a third-party authentication provider?

The provider sets its own cookie flags. You can't change them, so you're trusting the provider. Big providers (Google, Auth0, Clerk, Stripe) set them correctly. Check for yourself in DevTools after a login flow.

Does `SameSite=Lax` break anything I care about?

Almost never. The difference between None and Lax is whether the cookie is sent on cross-site requests from iframes / forms / fetches. Modern apps rarely depend on this. If yours does, you'll notice during testing.

References

Related explainers

Want Vantyris to check your domain for this and 196 other problems?

The teaser scan is free and needs no card. A verified scan starts at $10€10£10A$15¥1,500AED 40 and comes with the workspace: finding workflow, score trend, three PDF layouts, share links and monitoring.

Run a free check →Browse all explainers

Written by Vantyris