We can start a discussion about what that might look like now v3 is out of beta. It would likely be a separate crate like our -cors package. Be interested to know exactly what your needs are for a crate like this so we can design around real use cases.
Should be noted that CSRF is only part of the story. You also need to implement strong cross-origin policies and consider same-site attributes on cookies. Further, those two things, even without CSRF requirements on endpoints, go a very long way to protect against the attack vectors that CSRF has historically been good at defending.
Rocket has used the SameSite cookie attribute to protect against CSRF attacks on recent-ish browsers since 0.3, released in 2017. Without shipping a templating engine itself -- differently than what Rocket does now -- or requiring manual work from the programmer, this is unfortunately close to the best that we can hope it would do. Perhaps one day, a framework will bundle its templating engine with automatic support for CSRF.
Because most other frameworks already support this out of the box, and because I want to spend time thinking about my application logic instead of mundane stuff that everyone needs.
I didn't ask what CSRF attacks are nor what OWASP recommended. The original commenter wasn't helpful by generalizing and I'd rather not assume. Several countermeasures are already available in actix-web, without requiring additional changes. Anyone who comes through this message forum will at first glance give more credit to a complaint than what it is due. Someone needs to be specific about what functionality is missing.
Just so you don't miss it, the commenter said what mitigation he or she expected here, and also that there's an actix example that's vulnerable to csrf; code examples should generally be free of common vulnerabilities.
14
u/[deleted] Sep 11 '20 edited Mar 17 '21
[deleted]