SameSite docs use cross-origin terminology and are imprecise about Lax behavior

[andrealungh1]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies

What specific section or headline is this issue about?

SameSite

What information was incorrect, unhelpful, or incomplete?

The documentation uses the term cross-origin when describing SameSite behavior. However, SameSite is defined in terms of site (scheme + eTLD+1), not origin. Using cross-origin terminology is misleading and can cause confusion.

Additionally the description of SameSite=Lax is technically correct but imprecise. It does not clearly distinguish between:

• cross-site top-level navigations vs cross-site subresource requests
• safe HTTP methods (such as GET) vs unsafe/state-changing methods (such as POST)

What did you expect to see?

• Consistent use of cross-site terminology instead of cross-origin
• A more precise explanation of SameSite=Lax behavior that explicitly mentions top-level navigations and safe HTTP methods

Do you have any supporting links, references, or citations?

https://web.dev/articles/same-site-same-origin?hl=en
https://web.dev/articles/samesite-cookies-explained?hl=en

Do you have anything more you want to share?

No response

[wbamberg]

Yes. SameSite is documented correctly at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value. Perhaps this page could just link to that one for the definition of the values?

This page is also incorrect here:

Cookies that don't require access from JavaScript should have the HttpOnly directive set to block access, such as from Document.cookie. It is particularly important that session identifiers don't have JavaScript access, to help prevent attacks such as CSRF.

HttpOnly doesn't protect against CSRF. In CSRF the attacker doesn't care about accessing the session ID value itself, it just cares that the ID is sent with the cross-site request, so that the request is allowed. HttpOnly protects against a successful client-side XSS attack being able to steal the session ID.

In general I'm not that sure what to do about this and related pages. Their history is that they are background docs for the Mozilla Observatory, which makes it a little difficult for us to change/reorg/move them, which leads us into duplication between this content and other pages, which leads to errors and inconsistences.

These days I tend to think it might be better for us to brand these pages explicitly as background docs for the MO, instead of treating them as generic security guidelines.