Use server-side anti-forgery validation on any state-changing form or endpoint, and make the token part of the request so it cannot be predicted or reused by an attacker. In ASP.NET Core MVC, the common pattern is to include the hidden token in the form and validate it on the server before processing the action.
How CSRF protection works in MVC applications
csrf protection is effective when the server can verify that a request was initiated from your application, not from a third-party site. In MVC apps, that usually means pairing a token issued by the server with the user’s session and checking both values before any action that changes data.
The important detail is that CSRF defence is not just a form-field convention. The token must be generated by your application, carried with the request, and validated server-side on every state-changing path. That makes the request harder to forge because an attacker cannot reliably guess or reuse a valid anti-forgery value.
For .NET teams, the practical rule is simple: protect any POST, PUT, PATCH, DELETE, or custom action that changes state, including non-form endpoints that are triggered from JavaScript. If a request can alter data, an anti-forgery check should be part of its normal execution path, not an optional extra applied only to visible HTML forms.
Where MVC implementations usually go wrong
The most common failure is partial coverage. Teams protect browser forms but forget JSON endpoints, custom controller actions, or AJAX calls that still mutate server state. That creates a false sense of safety because the application appears protected in the UI while a reachable endpoint remains forgeable.
Another mistake is treating the token as client-side decoration instead of a server-enforced control. A hidden field or request header only matters if the server validates it and rejects the action when the token is missing, malformed, expired, or not bound correctly to the user context.
Implementation details also matter. If anti-forgery tokens are copied into places where they can be cached, logged, or reused outside the intended session flow, you weaken the protection you were trying to add. The goal is to make the token usable by the legitimate browser session and useless to an off-site attacker.
Risk and Threat Considerations
CSRF is dangerous because it leverages an already-authenticated browser session. The attacker does not need to steal the victim’s password if they can trick the browser into submitting a valid request to a site that trusts ambient cookies or session state.
Failure mechanism: A state-changing endpoint accepts requests without a server-validated anti-forgery token, so the browser automatically attaches credentials to a forged cross-site request and the application processes it as legitimate.
Impact: Attackers can trigger unintended transfers, profile changes, password changes, permission changes, or other destructive state changes, often without visible compromise of the victim’s account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | CSRF defence depends on controlling which authenticated requests may change state. |
| Recommendation — Enforce access control checks and validate that only intended authenticated requests can change application state. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Anti-forgery tokens are request-bound secrets that must not be reused or exposed. |
| Recommendation — Treat request-bound tokens as sensitive material and ensure they are generated, validated, and rotated correctly. | ||
Practitioner Guidance
What to verify: Confirm that every state-changing MVC action is protected by a server-side anti-forgery check, including endpoints called by JavaScript, and that unsafe requests fail closed when the token is absent or invalid. Also verify that your authentication flow does not rely on cookie presence alone for trust decisions.
Common mistake: Teams often secure visible forms and overlook API-style controller actions that are still reachable from a browser. If the action changes data, treat it as a CSRF target even when the payload is JSON or the caller is a single-page front end.
Practitioner takeaway: CSRF protection is only strong when validation is universal, server-enforced, and tied to the actual state-changing path, not just to the presence of a form on the page.
Related resources from NHI Mgmt Group
- How should security teams implement CSRF protection in Node.js applications?
- How should teams implement CSRF protection in Angular applications that use cookie-based sessions?
- How should security teams implement MFA in web applications without creating inconsistent protection?
- How should security teams prevent SQL injection in .NET applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
