How should ASP.NET Core teams prevent CSRF when they add POST actions manually?

How to prevent CSRF when adding POST actions in ASP.NET Core

ASP.NET Core teams should default to framework-wide anti-forgery validation, so every unsafe POST is checked unless the action is explicitly exempted. That reduces the chance that a new controller method is added without protection. The main failure mode is relying on per-action attributes and assuming every developer will remember to apply them consistently.

Why manual anti-forgery attributes create avoidable gaps

Manual decoration works only when every state-changing endpoint is discovered, reviewed, and kept in sync with the application’s routing and controller structure. In practice, new POST actions get added during feature work, and omission is easy to miss in code review or when a controller is refactored. Global validation shifts the burden from individual memory to a default security posture.

That matters because CSRF is not about malicious code execution in the browser, it is about a trusted authenticated session being reused to trigger an action the user did not intend. If one POST action is left unprotected, the browser can still submit it with ambient credentials, so a single missed endpoint can become a real state-change path.

Why global validation plus selective exceptions is the safer pattern

AutoValidateAntiforgeryToken is a good default because it checks unsafe HTTP methods automatically while avoiding friction on safe requests. That gives teams a simpler rule: validate by default, then opt out only for endpoints that are genuinely safe or have another explicit trust model. It is easier to audit and much harder to forget than sprinkling anti-forgery documentation style attributes across controllers.

That default still needs disciplined exception handling. If an endpoint is exempt, the reason should be obvious from the code and from the review trail, because the risk is not the attribute itself, it is creating an unreviewed state-changing path that bypasses the normal CSRF check.

Risk and Threat Considerations

CSRF exposure in ASP.NET Core usually comes from incomplete coverage, not from the protection mechanism itself. The practical risk is that a newly added POST action, especially one introduced during a hurried feature change, inherits cookie-based authentication but not the anti-forgery check.

Failure mechanism: A state-changing endpoint accepts a browser-submitted request with valid session credentials, and the missing anti-forgery token check allows an attacker-controlled page to trigger the action cross-site.

Impact: The user’s authenticated session can be abused to change data, submit forms, or trigger privileged workflow steps without the user’s intent.

Practitioner Guidance

What to verify: Confirm that the application uses a default anti-forgery policy for unsafe verbs, then review every deliberate exception as a security decision rather than a convenience change. If a controller action mutates data, it should be treated as protected unless there is a documented reason it cannot be.

Common mistake: Teams often protect the obvious form handlers and miss secondary POST endpoints added later for AJAX, partial updates, or admin workflows. Static analysis and review checks are valuable because they catch the mismatch between “we intended to protect POSTs” and “this specific action was actually annotated.”

Practitioner takeaway: The safest CSRF posture is a secure default with narrow, explicit opt-outs, because consistency is what prevents the one missed POST action from becoming the bypass.

Related resources from NHI Mgmt Group

• How should development teams prevent broken authentication in ASP.NET Core applications?
• How should teams implement claims-based authentication in ASP.NET Core without weakening access control?
• How should development teams implement HSTS in ASP.NET Core to reduce SSL stripping risk?
• How should teams reduce controller bloat in ASP.NET Core applications without losing maintainability?