Should my session cookie be SameSite=None?

Almost never. Use Lax or Strict for login. Reserve None+Secure for a cookie whose only job is a documented cross-site embed.

Is SameSite=Lax enough without CSRF tokens?

Lax reduces a class of cross-site POSTs. You still want CSRF defenses on state-changing forms. See the CSRF vs SameSite guide.

Will RoastMyOpsec see my embed cookie?

Only if Set-Cookie is on the audited URL's response. Login-issued cookies are often missing from a public landing roast.

Safety

SameSite=None vs Lax for Third-Party Embeds

August 21, 2025

SameSite=None vs Lax for third-party embeds is a cookie-attachment decision, not a branding toggle. SameSite=Lax (or Strict) keeps the session cookie off most cross-site POSTs and off many cross-site navigations. SameSite=None requires Secure and is how a cookie is sent in a cross-site iframe or other third-party context. Marketing homepages should keep auth cookies on Lax or Strict. If an embed must authenticate, use a dedicated embed cookie with None+Secure — not the main session name. Pair with CSRF tokens for state-changing forms. RoastMyOpsec grades session-like Set-Cookie flags on the URL you paste. It does not log in, does not load third-party iframes as a user, and does not send CSRF PoCs.

The practical difference

Lax is the modern default story for first-party sessions: top-level GETs may still send the cookie; classic cross-site POSTs often will not. Strict is tighter and can break return-from-payment flows. None is 'always send on HTTPS cross-site' — which is what trackers wanted, and what CSRF loves if that cookie is also your vault key.

Chrome's third-party cookie changes make None less of a tracker free-for-all, but a session cookie marked None is still the wrong shape for a brochure login.

How to choose based on the cookie's job

Session / auth: Lax or Strict, HttpOnly, Secure, preferably __Host-. Preference or theme cookies: Lax is fine; they should not authorize anything. Embed that must know the user inside another site's iframe: a separate cookie, None+Secure, partitioned if you use CHIPS, never the same name as wordpress_logged_in.

SameSite	Typical use	Cross-site iframe	Takeaway
Lax	First-party session	Usually not sent	Default for login cookies
Strict	High-sensitivity session	Not sent	Test checkout return URLs
None; Secure	Explicit embed/SSO cookie	Sent on HTTPS	Dedicated name; still CSRF-defend
None on the session cookie	Widget asked nicely	Session rides along	Don't

What the roast can see

Landing Set-Cookie attributes only. Cookies issued after login are often invisible. A marketing pixel cookie with None is a privacy/OPSEC smell; an auth cookie with None is a finding. See HttpOnly vs Secure vs SameSite and CSRF vs SameSite.

Common mistakes

The first mistake is SameSite=None on every cookie 'for Safari.'

The second mistake is None without Secure, which browsers reject.

The third mistake is treating Lax as a complete CSRF defense for every POST.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Should my session cookie be SameSite=None?: Almost never. Use Lax or Strict for login. Reserve None+Secure for a cookie whose only job is a documented cross-site embed.
Is SameSite=Lax enough without CSRF tokens?: Lax reduces a class of cross-site POSTs. You still want CSRF defenses on state-changing forms. See the CSRF vs SameSite guide.
Will RoastMyOpsec see my embed cookie?: Only if Set-Cookie is on the audited URL's response. Login-issued cookies are often missing from a public landing roast.