[breaking] Defer antiforgery/CSRF rejection to form consumers via IAntiforgeryValidationFeature

[DeagleGross]

Summary

CsrfProtectionMiddleware no longer short-circuits a cross-origin request. Instead it records its verdict on IAntiforgeryValidationFeature — the same feature the token-based AntiforgeryMiddleware uses — and lets the request continue. Downstream components read that verdict and reject the request when they actually consume the form. This unifies cross-origin CSRF and token antiforgery behind a single verdict, and makes consumers (like Razor Components) defer to whichever middleware ran instead of validating on their own.

Validation is lazy (forms vs. not touching forms)

A recorded IsValid == false verdict does nothing on its own — the request is only rejected when a component reads the form (or otherwise inspects the feature):

• Endpoint that reads the form (MVC action with antiforgery, minimal API [FromForm], Blazor SSR form POST): the invalid verdict is observed and the request is rejected with 400.
• Endpoint that never touches the form: nothing reads the feature, so the request proceeds. This matches how token antiforgery already behaves — an unsafe request with a bad/missing token is not rejected unless the form is actually read.

Where the verdict is read and the request is rejected

Four consumers read IAntiforgeryValidationFeature and reject on IsValid == false. Each first confirms a middleware actually ran (an HttpContext.Items marker for Antiforgery or CSRF) before trusting the verdict:

1. AntiforgeryMiddlewareAuthorizationFilter — MVC
2. RequestDelegateFactory — minimal APIs binding [FromForm]
3. FormFeature — backstop when the form is read directly
4. RazorComponentEndpointInvoker — Blazor SSR

Token validation overrides CSRF

When an app calls UseAntiforgery(), the token middleware runs after CSRF and is authoritative: it clears any prior CSRF verdict and re-records the result of token validation. A request CSRF-marked invalid can be overridden to valid by a successful token check, and vice versa.

Razor Components behavior change (breaking)

RazorComponentEndpointInvoker no longer calls IAntiforgery.ValidateRequestAsync itself. It trusts the verdict left by the upstream middleware and returns 400 only when IAntiforgeryValidationFeature.IsValid == false. It also skips antiforgery token generation when no token middleware ran. Apps which calls UseAntiforgery() see no change. Apps that removed UseAntiforgery() (see #67119) are now protected by the auto-injected CSRF middleware instead of token antiforgery.

flowchart TB
    R[Request] --> CSRF[CsrfProtectionMiddleware<br/>auto-injected · records verdict on IAntiforgeryValidationFeature · no short-circuit]
    CSRF --> AF[UseAntiforgery optional<br/>token validation overrides the CSRF verdict]
    AF --> ROUTING[Routing · matches endpoint]
    ROUTING --> EM[EndpointMiddleware<br/>safety check: AF or CSRF marker present?]
    EM --> INV[RazorComponentEndpointInvoker<br/>reads IAntiforgeryValidationFeature → 400 if IsValid is false]
    INV --> RND[EndpointHtmlRenderer · renders component tree]
    RND --> SP[EndpointAntiforgeryStateProvider<br/>AF marker → can generate token?]
    SP --> TOK[&lt;AntiforgeryToken /&gt; · emits __RequestVerificationToken input]

Loading

Notes

• Not the full MapRazorComponents unexpectedly requires antiforgery middleware #51981 fix: a pure-antiforgery app that never calls UseAntiforgery() still throws on a required endpoint when neither middleware ran (e.g. DisableCsrfProtection=true, or a non-WebApplication host). The EndpointMiddleware marker check is what enforces this.

---

Related #51981
Closes #67081

[dotnet-policy-service]

Thanks for identifying a breaking change.

@DeagleGross, after you commit this PR please take the following actions, as part of the breaking changes announcement process:
\n- [ ] Create an announcement issue by using the ASP.NET Core breaking change issue template.
\n- [ ] Link the breaking change announcement issue from this PR.
\n- [ ] Remove the needs-breaking-change-announcement label.

[Copilot]

Pull request overview

This PR changes Razor Components antiforgery behavior to defer to the upstream antiforgery/CSRF middleware “verdict” (via IAntiforgeryValidationFeature) instead of directly validating tokens inside the RazorComponentEndpointInvoker. It also introduces shared HttpContext.Items marker keys so downstream components can detect whether either Antiforgery or CSRF middleware ran for the matched endpoint.

Changes:

• Introduce shared MiddlewareInvokedKeys and have Antiforgery/CSRF middleware set endpoint-invoked markers in HttpContext.Items.
• Update EndpointMiddleware’s “missing antiforgery middleware” safety check to accept either the Antiforgery marker or the CSRF marker.
• Update Razor Components endpoint invocation and token emission to rely on middleware-set validation state and to mint/store tokens only when Antiforgery middleware actually ran.

Show a summary per file

File	Description
src/Shared/MiddlewareInvokedKeys.cs	Adds shared HttpContext.Items keys (and sentinel) for middleware-invoked markers.
src/Http/Routing/test/UnitTests/EndpointMiddlewareTest.cs	Adds unit coverage for the CSRF marker satisfying the antiforgery-middleware presence check; updates existing key usage.
src/Http/Routing/src/Microsoft.AspNetCore.Routing.csproj	Links the new shared MiddlewareInvokedKeys.cs into the Routing assembly.
src/Http/Routing/src/EndpointMiddleware.cs	Accepts either Antiforgery or CSRF marker as satisfying the antiforgery middleware requirement check.
src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/CsrfProtectionIntegrationTests.cs	Adds integration tests asserting CSRF middleware sets the marker when an endpoint is matched (including when antiforgery is disabled on the endpoint).
src/DefaultBuilder/src/Microsoft.AspNetCore.csproj	Links the new shared MiddlewareInvokedKeys.cs into the DefaultBuilder assembly.
src/DefaultBuilder/src/Internal/CsrfProtectionMiddleware.cs	Sets the CSRF marker when an endpoint is present before performing validation/skip logic.
src/Components/Endpoints/test/RazorComponentEndpointInvokerTest.cs	Adds tests for invoker behavior when IAntiforgeryValidationFeature is valid/invalid/absent.
src/Components/Endpoints/test/Forms/EndpointAntiforgeryStateProviderTest.cs	Adds tests to ensure token generation is gated on the Antiforgery marker and can be disabled.
src/Components/Endpoints/src/RazorComponentEndpointInvoker.cs	Removes endpoint-level antiforgery validation; relies on IAntiforgeryValidationFeature and gates token storage on the Antiforgery marker.
src/Components/Endpoints/src/Microsoft.AspNetCore.Components.Endpoints.csproj	Links the new shared MiddlewareInvokedKeys.cs into the Components Endpoints assembly.
src/Components/Endpoints/src/Forms/EndpointAntiforgeryStateProvider.cs	Gates _canGenerateToken on the Antiforgery marker instead of assuming token generation is always possible.
src/Antiforgery/src/Microsoft.AspNetCore.Antiforgery.csproj	Links the new shared MiddlewareInvokedKeys.cs into the Antiforgery assembly.
src/Antiforgery/src/AntiforgeryMiddleware.cs	Sets the shared Antiforgery marker in HttpContext.Items when an endpoint is present.

Copilot's findings

• Files reviewed: 14/14 changed files
• Comments generated: 2

[javiercn]

@DeagleGross might be worth looking also at AntiforgeryToken (the component in Blazor). Not sure what happens if AF is disabled and the component is rendered into the page.

[DeagleGross]

@DeagleGross might be worth looking also at AntiforgeryToken (the component in Blazor). Not sure what happens if AF is disabled and the component is rendered into the page.

AntiforgeryToken already handles null tokens gracefully:

aspnetcore/src/Components/Web/src/Forms/AntiforgeryToken.cs

Lines 31 to 34 in da04fcb

	if (_requestToken != null)
	{
	_handle.Render(RenderField);
	}

I've verified that having <AntiforgeryToken /> component on the page will be a no-op without any failure.

[DeagleGross]

/ba-g unrelated: macOS quarantined-pr job timeouts

[pablopioli]

The current implementation recognizes only the traditional safe HTTP methods (e.g., GET and HEAD). However, recent versions of ASP.NET introduce the QUERY HTTP method. Since QUERY is not included in the current list of safe methods, it is incorrectly treated as a potentially unsafe method. The implementation should be updated to recognize QUERY as a safe HTTP method.

[BrennanConroy]

Please file an issue, we don't track comments on closed PRs.