CSRF Protection in ASP.NET Core: Antiforgery Tokens vs SameSite Cookies vs JWT — Enterprise Decision Guide

Cross-site request forgery (CSRF) remains one of the most misunderstood threats in enterprise ASP.NET Core applications. Senior architects regularly ask the same question in design reviews: do we actually need antiforgery tokens in this API, or are SameSite cookies and JWT enough? The answer depends on your authentication model, your client surface, and how seriously you take defence-in-depth — and getting it wrong costs you either false security or unnecessary complexity.

---

🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets

---

Why CSRF Still Matters for Enterprise APIs

CSRF exploits the fact that browsers automatically attach cookies to every request to a matching origin. When a user is authenticated via a session cookie and visits a malicious page, that page can silently forge requests to your API — complete with the user's valid session. Enterprise systems that mix browser-based frontends with server-side rendered pages, SPAs, and internal tooling are particularly exposed because they often support multiple authentication modes simultaneously.

The confusion arises because modern defences overlap. SameSite cookies, antiforgery tokens, and JWT bearer authentication all reduce CSRF risk, but they do so at different layers and with different trade-offs. Choosing the wrong combination leads to gaps that attackers can exploit, or to validation overhead that breaks legitimate cross-origin integrations.

Understanding the Three Defence Layers

Antiforgery Tokens (Double-Submit Cookie Pattern)

ASP.NET Core's built-in IAntiforgery service implements the synchroniser token pattern. When the server renders a form or issues a token endpoint response, it writes a value both into a HttpOnly cookie and into the form body (or a response header). On the next mutating request, ASP.NET Core compares the two values. An attacker's forged request carries the cookie automatically but cannot read its HttpOnly value to populate the second channel — so the validation fails.

This is the gold standard for cookie-authenticated applications because it does not rely on browser vendor implementation of SameSite. It works in every browser, including legacy environments where SameSite support is incomplete or inconsistently applied.

The downside is operational friction. Every mutating endpoint must participate in token issuance and validation. For APIs consumed by non-browser clients — mobile apps, server-to-server integrations, CI pipelines — antiforgery validation requires custom header handling and can break standard tooling unless you explicitly configure exempt paths.

SameSite Cookie Attributes

Setting SameSite=Strict or SameSite=Lax on authentication cookies tells modern browsers not to include those cookies on cross-origin requests. A malicious page on evil.com that triggers a POST to yourapp.com will not receive the authentication cookie, so the request arrives unauthenticated and fails at the authorisation layer before it reaches your business logic.

SameSite is highly effective as a primary CSRF defence in greenfield enterprise applications targeting modern browsers, but it has two critical caveats:

1. Browser support gaps: Older Chromium builds, certain iOS WebView configurations, and some enterprise proxy environments mishandle SameSite cookies. If your enterprise user base includes managed devices running older browser versions, SameSite alone is insufficient.
2. Cross-origin legitimate scenarios: B2B integrations, embedded widgets, and payment callbacks require SameSite=None; Secure. Once you set None, SameSite provides zero CSRF protection for those flows, and you need an alternative.

JWT Bearer Tokens

Stateless bearer token authentication is inherently CSRF-resistant because browsers do not automatically attach Authorization headers the way they do cookies. A forged request from a malicious page cannot include a valid JWT unless the attacker has already compromised the token — which is an XSS problem, not a CSRF problem.

If your API is a pure REST or gRPC service consumed only by SPAs, mobile clients, or server-to-server clients using bearer authentication, you do not need antiforgery tokens. The authentication model itself eliminates the attack vector.

The critical caveat: if you store JWTs in cookies (a common pattern for SSR applications or next-generation full-stack frameworks), you are back to cookie-based authentication and CSRF exposure.

The Decision Matrix: Which Protection Do You Actually Need?

Scenario	Antiforgery Tokens	SameSite Cookies	JWT Bearer	CSRF Risk
MVC app with Razor forms + cookie auth	✅ Required	✅ Add as second layer	N/A	High if missing
Blazor Server + cookie auth	✅ Required	✅ Recommended	N/A	High if missing
SPA + REST API + JWT bearer (Authorization header)	❌ Not needed	N/A	✅ Inherently safe	Negligible
SPA + REST API + JWT stored in cookie	✅ Required	✅ Recommended	⚠️ Cookie changes the risk	High if missing
Multi-tenant API with B2B cross-origin integrations	❌ Impractical	⚠️ Must be None for cross-origin	✅ Use bearer	Medium — depends on auth
Internal admin tools with Windows/Kerberos auth	✅ Required	✅ Strict	N/A	High if missing

When to Use Antiforgery Tokens in ASP.NET Core

Enable antiforgery validation when all three conditions apply:

1. Your application uses cookie-based authentication (ASP.NET Core Identity, session cookies, or JWTs stored in cookies)
2. At least one client is a browser (Razor Pages, MVC views, Blazor, SPAs that store auth in cookies)
3. Your endpoints perform state-mutating operations (POST, PUT, PATCH, DELETE that change data, trigger side effects, or authorise transactions)

In ASP.NET Core, Razor Pages and MVC with form tag helpers inject antiforgery tokens automatically. For controller-based APIs, you opt in via [ValidateAntiForgeryToken] on individual actions or [AutoValidateAntiforgeryToken] globally. For Minimal APIs, you use the WithAntiforgery() extension or call IAntiforgery.ValidateRequestAsync() in an endpoint filter.

What to Exclude from Antiforgery Validation

Not every endpoint needs validation. Safe exclusions include:

• GET, HEAD, OPTIONS, TRACE endpoints (idempotent, read-only)
• Endpoints exclusively consumed by non-browser clients (verified via API key, client certificate, or mTLS)
• Webhook receiver endpoints where the caller cannot obtain a token (use HMAC signature validation instead)
• OAuth/OIDC callback endpoints (the anti-CSRF protection there is the state parameter, not your antiforgery middleware)

When to Rely on SameSite Cookies Without Antiforgery Tokens

SameSite without antiforgery is acceptable for new applications where:

• You control the entire client surface and it targets evergreen browsers (Edge, Chrome, Firefox, Safari 2021+)
• You have no legacy client requirements or enterprise managed-device constraints
• Your session cookies are SameSite=Strict or SameSite=Lax with no cross-origin exceptions
• You have a Content Security Policy that prevents injected scripts from making credentialed requests

Even in this scenario, Microsoft and OWASP both recommend antiforgery tokens as a defence-in-depth measure. SameSite should be a complement, not a replacement.

Is the Referer / Origin Header Check a Valid Alternative?

Some teams validate the Referer or Origin request header as a lightweight CSRF check. This is better than nothing but is not production-grade for enterprise APIs:

• Browsers may omit the Referer header for privacy reasons or under certain CSP directives
• Proxies can strip headers
• The Origin header is more reliable but can still be absent on cross-origin GET redirected to POST
• Header-only validation does not constitute a cryptographic proof of token ownership

Use header checking only as a defence-in-depth supplement, never as a primary CSRF control.

How This Fits Your Broader ASP.NET Core Security Posture

CSRF protection is one layer in a broader API security posture. For enterprise teams building production-grade ASP.NET Core APIs, CSRF validation works best alongside consistent ASP.NET Core Authorization strategies so the authorisation layer enforces identity regardless of how CSRF validation is configured — and with proper global exception handling to ensure security-related failures return structured ProblemDetails responses without leaking stack traces.

For a complete reference on token configuration options and attribute semantics, the Microsoft documentation on preventing CSRF attacks in ASP.NET Core is the authoritative source.

Common Anti-Patterns to Avoid

Anti-pattern 1: Disabling antiforgery globally because "it's an API" Many teams disable antiforgery project-wide when they have a hybrid app. This silently unprotects Razor Page forms. Scope exclusions to specific endpoints or controllers, not globally.

Anti-pattern 2: Storing JWTs in localStorage and treating the app as CSRF-safe, then later moving to cookie storage without revisiting CSRF controls This is the most common enterprise security regression. JWT storage decisions are architecture decisions — they must be reviewed each time the auth model changes.

Anti-pattern 3: Using antiforgery tokens for server-to-server webhook integrations Webhooks from external systems cannot obtain antiforgery tokens. Require HMAC signature validation for all inbound webhooks and explicitly mark those endpoints with [IgnoreAntiforgeryToken].

Anti-pattern 4: Assuming SameSite=Lax fully protects top-level navigation POST requests Lax allows cookies on top-level GET navigations but not on cross-origin POST requests made directly. For high-risk mutating flows (financial transactions, privilege escalation), use Strict and antiforgery tokens together.

Enterprise Recommendation

For most enterprise ASP.NET Core applications in 2026:

1. Pure API (bearer auth, SPA or mobile client): No antiforgery needed. Ensure JWTs are not stored in cookies. Set CORS policy to allowlist only your known origins.
2. MVC/Razor Pages with cookie auth: Enable [AutoValidateAntiforgeryToken] globally, add [IgnoreAntiforgeryToken] to API-only controllers serving non-browser clients.
3. Blazor Server: Use the built-in antiforgery integration introduced in .NET 8. Do not bypass it.
4. Hybrid app (Razor Pages + API controllers + SPAs): Layer all three mechanisms — antiforgery tokens for form submissions, SameSite=Strict on session cookies, and bearer tokens for API-to-API calls.
5. All scenarios: Set SameSite=Lax as the floor for authentication cookies. Upgrade to Strict wherever cross-origin requests are not part of your design.

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

FAQ

Does a REST API need antiforgery tokens?

Only if the API uses cookie-based authentication and is consumed from a browser. If clients authenticate exclusively via Authorization: Bearer headers, the browser's same-origin policy prevents CSRF attacks without any additional tokens.

What is the difference between SameSite=Lax and SameSite=Strict for CSRF protection?

Strict prevents the authentication cookie from being sent on any cross-origin request, including top-level navigation links. Lax allows the cookie on top-level GET navigations but not on cross-origin form submissions. For applications where users arrive via external links, Lax is the practical choice; for applications with no legitimate cross-origin navigation, Strict provides stronger protection.

Can I rely solely on SameSite cookies without antiforgery tokens?

In modern browser-only environments, SameSite=Strict is a strong control. However, Microsoft's official guidance recommends defence-in-depth: use both SameSite and antiforgery tokens for mutating endpoints in cookie-authenticated applications.

How do I configure antiforgery tokens globally in ASP.NET Core?

For MVC, apply [AutoValidateAntiforgeryToken] as a global filter in AddControllersWithViews(). For Razor Pages, validation is on by default. For Minimal APIs in .NET 8+, call WithAntiforgery() on endpoint groups. Configure the cookie name, expiry, and SecurePolicy through services.AddAntiforgery(options => { ... }).

Does JWT authentication completely eliminate CSRF risk?

Yes, when the JWT is transmitted exclusively via the Authorization header. The risk returns if you store the JWT in a cookie, because browsers do attach cookies automatically. In that case, treat the application as cookie-authenticated and apply antiforgery controls.

What happens if I skip antiforgery validation in a Blazor Server application?

Blazor Server uses a persistent SignalR connection. The initial page load is vulnerable to CSRF if antiforgery is not validated. .NET 8 introduced built-in antiforgery support for Blazor that validates the initial HTTP request before establishing the SignalR circuit. Bypassing it exposes the entire application to session hijacking via CSRF on the initial connection.

How should I handle antiforgery for webhook endpoints?

Mark webhook receiver endpoints with [IgnoreAntiforgeryToken] and implement HMAC-SHA256 signature validation instead. The webhook sender signs the payload with a shared secret; your endpoint verifies the signature before processing. This is more appropriate than antiforgery tokens because webhook senders are server-to-server clients that cannot obtain tokens through a browser flow.