I've made a couple of updates here, but I've not added "by setting SameSite to Strict" — the end of the paragraph and the following sub-bullets detail which values to use.

Are you saying you think it should always be set to Strict? I thought Lax was OK if Strict caused problems?

My point is that setting SameSite to strict prevents

sending the cookie via cross-origin requests (for example from {{htmlelement("img")}} element), as a strong anti-CSRF measure.

Setting SameSite to lax which is the same as not setting SameSite at all, allows sending the cookie via cross-origin requests, potentially enabling CSRF attacks.

Are you saying you think it should always be set to Strict? I thought Lax was OK if Strict caused problems?

No, you're right, that lax is needed if using strict causes problems, but I just want to make sure it's clear that only setting Samesite to strict will a strong anti-CSRF measure. Setting Samesite to lax does not.

Thanks for the clarification. I've updated this section to the following:

• SameSite

  • : Forbid sending cookies via cross-origin requests (for example from {{htmlelement("img")}} elements) using SameSite. You should use one of the following two values:

    • SameSite=Strict: Only send the cookie when your site is directly navigated to. This is a strong anti-CSRF measure, so use this value if possible.
    • SameSite=Lax: Additionally send the cookie when navigating to your site from another site. This is the default behavior used in modern browsers if no SameSite directive is set, and should only be used if Strict is too restrictive.

    Both of the above values are useful in protecting against Clickjacking attacks in cases that rely on the user being authenticated.

Looks great! 👍

Setting SameSite to lax which is the same as not setting SameSite at all, allows sending the cookie via cross-origin requests, potentially enabling CSRF attacks.

That's not true. Only Chrome sets SameSite=lax by default, and funnily there are some caveats too. The explicit setting is more stricter than the implied, due to Chrome being to aggressive during roll-out and not feeding their changes back properly to the standards. https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-10.html#section-5.4.7.2.

Ah. Do I need to update the text I've used here then?

@mozfreddyb what should I say?

Something along the lines of
... while in theory, strict would be a good setting, we know it's breaking navigations (users clicking a link to arrive at the website appears not to be logged in, while the browser has in fact omitted the cookies on purpose).

The best middleground is to something like this

• use strict only on csrf/xsrf tokens
• use strict everywhere, but do a refresh/reload/cookie-check in javascript during every page load iff there's an indication that the user is logged in but not sending all cookies

This isn't fully true. If you are navigating from a.example to b.example, the cookies will be omitted. They are only sent when the navigation is same-site.

Thus, SameSite=strict is breaking pages left and right.

OK, I've updated this wording to

SameSite=Strict: Only send the cookie on same-site navigations. Cookies are omitted on same-origin navigations (e.g. a.example.com to b.example.com). This is a very strict setting, but it does provide strong CSRF protection, so use this value if possible.

Cookies are omitted in cross-site requests (hotlinking) and also on cross-site navigation (e.g., when following a link from a different web page). Cookies will be only sent in same-site contexts (context here meaning navigation & other requests)

"additionally" seems odd when you have to pick one of the settings.

Agreed. I've updated it to

SameSite=Lax: Send the cookie on same-site and same-origin navigations, and when navigating to your site from another site. This is the default behavior used in modern browsers if no SameSite directive is set, and should be used if Strict is too restrictive.

• Remember that navigations are not the most interesting thing for CSRF / same-site cookies, but inclusion of cross-origin resources from attackers is.

• same-site is a superset of same-origin-

How about "Only send the cookie in same-site requests but also when navigating to your website."

• Omit the "default behavior in modern browsers". Only Chrome ships this and Firefox currently has no intention of shipping it.

It's unclear what kind of protection this is serving from the sentence above. The request is going to be sent anyway. This is a protection of the response, no?

Yeah, that phrasing is a bit weird. I've updated it to:

Cross-Origin Resource Policy (CORP) is set by the {{httpheader("Cross-Origin-Resource-Policy")}} header, which lets websites and applications opt-in to protection against vulnerabilities related to certain cross-origin requests (such as those made by the {{htmlelement("script")}} and {{htmlelement("img")}} elements).

Is that any better? The solution section explains that it works by stripping out the response body.

it is :) thanks

How about "....recommended for URLs that reply with sensitive user information or private APIs"?

like it; updated

"If, in turn, your page requires access to cross-origin resources, ...."

Note that COEP is a header that needs to be set on the requesting page and CORP is a header that needs to be sent from the page that is returning the response.

I've updated this paragraph to

If, in turn, your site requires access to cross-origin resources, opt into a better default by sending a {{httpheader("Cross-Origin-Embedder-Policy")}} header along with the associated requests. This will prevent loading of cross-origin resources that don't also explicitly send a Cross-Origin-Resource-Policy: cross-origin header.

I've also updated some of the earlier wording about CORP to say that it is recommended on responses. I've also stated that it is a response header in the intro.

I don't understand. What's the word "all" doing here?

Wasting space, I think. Removed ;-)