Suggestion: add new section 6.1.3.3.3. Use Anti-forgery cookies

[damienbod]

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.

[philippederyck]

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?

[damienbod]

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.

[aaronpk]

@damienbod 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?

[damienbod]

Hi @aaronpk I'll write something

Kind regards Damien

[damienbod]

@aaronpk @philippederyck

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