ASP.NET Core in .NET 11 preview 6 introduces a new CSRF protection mechanism based on Fetch Metadata HTTP headers (Sec-Fetch-Site, Sec-Fetch-Mode, etc.) instead of the traditional synchronizer token pattern. The new approach avoids the operational overhead of the Data Protection system, eliminates multi-tab token invalidation issues, and reduces per-request cryptographic work. The algorithm checks whether requests are safe HTTP verbs, whether they originate from the same origin, and whether a CORS policy permits the origin before allowing or denying. The new CsrfProtectionMiddleware is added automatically to WebApplicationBuilder pipelines. Blazor SSR and minimal APIs benefit cleanly from the new approach, but MVC and Razor Pages continue to generate and validate tokens in addition, requiring significant hacking to opt out entirely. Cross-origin form posts can be permitted by configuring CORS allowed origins rather than disabling CSRF entirely.

16m read timeFrom andrewlock.net
Post cover image
Table of contents
What is Cross-Site Request Forgery (CSRF)?How does the existing CSRF protection work in ASP.NET Core?Why do we need a new anti-CSRF feature in ASP.NET Core?A recap on Fetch Metadata HTTP headersUpdating the anti-CSRF algorithm in ASP.NET CoreModifying your application to support the new middlewareWait, why am I still seeing tokens, and getting 400 errors if they're not present?Summary
2 Impressions