Original text:
the frontend and the BFF do not require any preflights, so there's no additional overhead.  6.1.3.4. In the BFF pattern, all OAuth responsibilities have been moved to the

Reviewer comments:
fixes URL
Thanks NAME I like it, I updated the PR
Because the UI and the backend APIs can be hosted from the same backend application, Anti-forgery tokens can also be used to protect against CSRF.
There are indeed various CSRF defenses that could be used in this architecture. The two options discussed in the current document explicitly focus on defenses that are part of the core web platform, and require minimal effort from the developer to implement. The use of anti-forgery cookies requires code on both the frontend and the backend to guarantee their effectiveness. Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?
I thought it would be good to add this as it is per default supported in some tech stacks and so easy to use. People reading the doc might read it as only the mentioned ways protect against CSRF. Adding this would make the recommendations more complete. “Are there benefits to using anti-forgery cookies over samesite cookies/CORS that we're missing?” In my opinion, there are no benefits compared with the other two options, just another option. Samesite cookies/ anti-forgery cookies are also a viable option. If the used tech stack has this already supported per default, then there is less to do as a developer. This would make it an option.
NAME I am open to listing out this option as well for the scenario you mention. Do you have text you could suggest that captures this?
Hi NAME I'll write something Kind regards Damien
NAME NAME I created a PR with an initial draft. I don't think we should explain how it works because this is not the scope of this doc. kind regards Damien
Thanks for the suggestion NAME I believe it is important to explain why this addition is there, so I've taken a stab at rewording (see below). I have also removed some of the implementation details that are not necessarily relevant (e.g., the use of HTTPS). I also removed the note on encryption, since the value in the cookie is typically random, so there would be no need to encrypt the cookie. Let me know what you think.

Revised text:
the frontend and the BFF do not require any preflights, so there's no additional overhead. <ins> 6.1.3.3.3. Some technology stacks and frameworks have built-in CRSF protection using anti-forgery cookies.  This mechanism relies on a session- specific secret that is stored in a cookie, which can only be read by the legitimate frontend running in the domain associated with the cookie.  The frontend is expected to read the cookie and insert its value into the request, typically by adding a custom request header. The backend verifies the value in the cookie to the value provided by the frontend to identify legitimate requests.  When implemented correctly for all state changing requests, this mechanism effectively mitigates CSRF. Note that this mechanism is not necessarily recommended over the CORS approach.  However, if a framework offers built-in support for this mechanism, it can serve as a low-effort alternative to protect against CSRF. </ins> 6.1.3.4. In the BFF pattern, all OAuth responsibilities have been moved to the