Your authentication and authorization policies are nothing to do with CSRF. CSRF occurs when an authenticated user on your site visits another site, and that site is able to trick them into issuing a request to your site to perform an action which they are authorised to perform, but did not intend to initiate.
For example, you log in to
YourBankSite.com
. In the same browser session, you then visit
EvilBadGuys.net
. That site includes a button that reads
"Cutest kitten picture ever - click now!"
. When you click on that button, it submits a request to your bank's website to transfer $1,000,000 from your bank account to Dr Evil's bank account. You're authenticated on your bank's site; you're authorised to transfer money from your bank account; but you didn't intend to do so.
The solution is to add an anti-forgery token to all of the forms on your site. The server will append a token to your form in a hidden field. When the form is submitted, it will verify that the token is present, that it was generated by the server itself, and that it was generated for the current user. If any of those conditions are not met, then the request will be rejected. The other site will not be able to generate an appropriate token, and so it will not be able to initiate a forged request on your site.
Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core | Microsoft Learn[
^]
The other CSRF protection you'll want to use is to configure "same site" cookies:
SameSite | OWASP Foundation[
^]
Work with SameSite cookies in ASP.NET Core | Microsoft Learn[
^]
In all modern browsers, setting "same-site" to either "strict" or "lax" ensures that your cookies will not be sent with requests initiated from another site. However, this should be implemented
in addition to the anti-forgery token, since there may still be ways around it:
Bypassing SameSite cookie restrictions | Web Security Academy[
^]