Defer implicit middlewares to run after Routing

[DeagleGross]

The default-on CSRF protection wrongly rejected a legitimate cross-origin POST to an endpoint with a named CORS policy (.RequireCors("name") / [EnableCors("name")]) — but only when the app called app.UseRouting() explicitly. In that case the framework's implicit middleware ran before routing matched, so the endpoint (and its CORS policy) wasn't visible yet.

var builder = WebApplication.CreateBuilder(args);

string localOrigins = "local";
builder.Services.AddCors(o => o.AddPolicy(localOrigins, b =>
    b.WithOrigins("https://localhost:44463").AllowAnyMethod().AllowAnyHeader()));

var app = builder.Build();
app.UseHttpsRedirection();
app.UseRouting();
app.UseCors(localOrigins);
app.MapPost("/api/convert", () => Results.Ok(new { result = "converted" }))
   .RequireCors(localOrigins);
app.Run();

Fix

When the app calls UseRouting() explicitly, defer the framework's implicit authentication, authorization, and CSRF middleware into a block that runs immediately after routing matches — mirroring the order used when the framework adds UseRouting() itself. With implicit routing, behavior is unchanged.

The block is a stable, named framework method validated by EndpointRoutingMiddleware (method name + assembly + public-key-token) before it runs, so application code can't inject its own middleware into the reserved slot.

Tests

Integration tests in CsrfProtectionIntegrationTests.cs cover: explicit UseRouting() + named policy + allowed origin → 200 (the repro), the implicit-routing regression case, untrusted origin still → 400, and the trust-check (closure / wrong-assembly / non-delegate rejected, framework block accepted).

Fixes #67174

[Copilot]

Pull request overview

Fixes a pipeline-ordering bug where the default-on CsrfProtectionMiddleware can’t see per-endpoint CORS metadata (e.g., RequireCors("name")) when an app calls app.UseRouting() explicitly, causing allowed cross-origin POSTs to be incorrectly rejected.

Changes:

• Inject CSRF protection via a helper that can provide an on-demand endpoint matcher (via RerouteHelper) when routing hasn’t run yet.
• Update CsrfProtectionMiddleware to temporarily match an endpoint (when needed) to resolve per-endpoint metadata, then restore the pre-routing endpoint/route-values state.
• Add TestServer integration tests covering explicit vs auto routing, allowed vs untrusted origins, and ensuring the endpoint executes only once.

Show a summary per file

File	Description
src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/CsrfProtectionIntegrationTests.cs	Adds integration coverage for named CORS policies with explicit UseRouting() and regression guards.
src/DefaultBuilder/src/WebApplicationBuilder.cs	Changes CSRF auto-injection to optionally supply an endpoint-matching delegate when routing hasn’t executed yet.
src/DefaultBuilder/src/Microsoft.AspNetCore.csproj	Includes shared Reroute.cs to reuse the existing reroute/matching helper in this assembly.
src/DefaultBuilder/src/Internal/CsrfProtectionMiddleware.cs	Adds endpoint-resolution support and refactors verdict recording to work with temporary endpoint matching.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 1

[halter73]

I know this might sound a little weird, but since CsrfProtectionMiddleware is internal right now anyway, and we're trying to make it as automatic as possible especially now that it doesn't require data protection, should we just have the endpoint routing middleware call into the ICsrfProtection service directly?

Then it just works everywhere, and not just with WebApplicationBuilder. There's already some precedent for EndpointRoutingMiddleware handling some simple things internally that aren't exactly routing related like IRequestSizeLimitMetadata enforcement. We could consider having AddRouting add the DefaultCsrfProtection service implementation, but that might be a bridge to far because of the layering. I think logging a warning similar to what we do if the IHttpMaxRequestBodySizeFeature is missing might be our best bet.

Fix

Give the CSRF middleware an on-demand endpoint matcher (reusing the existing RerouteHelper pattern already used by UsePathBase, UseExceptionHandler, UseRewriter). When the endpoint isn't matched yet, CSRF matches it, records its verdict, then restores the pre-routing state so the rest of the pipeline is unaffected.

I think the problem with this approach other than only working with WebApplicationBuilder (which by itself isn't the end of the world), is that someone might call something like UsePathBase or UseRewriter after the CsrfProtectionMiddleware has already run routing and executed all its validation logic on potentially the wrong endpoint, and the CsrfProtectionMiddleware isn't rerun when the routing logic runs again later and matches the correct endpoint. @BrennanConroy Do you have thoughts on this? I know you've dealt with the existing RerouteHelper pattern a bit.

Absent integrating the ICsrfProtection into the endpoint routing middleware itself, I probably would prefer an explicit public UseCsrfProtection() method, but I'd lean towards just integrating it into the routing middleware since it's relatively simple and inexpensive.

[javiercn]

I know this might sound a little weird, but since CsrfProtectionMiddleware is internal right now anyway, and we're trying to make it as automatic as possible especially now that it doesn't require data protection, should we just have the endpoint routing middleware call into the ICsrfProtection service directly?

Then it just works everywhere, and not just with WebApplicationBuilder. There's already some precedent for EndpointRoutingMiddleware handling some simple things internally that aren't exactly routing related like IRequestSizeLimitMetadata enforcement. We could consider having AddRouting add the DefaultCsrfProtection service implementation, but that might be a bridge to far because of the layering. I think logging a warning similar to what we do if the IHttpMaxRequestBodySizeFeature is missing might be our best bet.

Fix

Give the CSRF middleware an on-demand endpoint matcher (reusing the existing RerouteHelper pattern already used by UsePathBase, UseExceptionHandler, UseRewriter). When the endpoint isn't matched yet, CSRF matches it, records its verdict, then restores the pre-routing state so the rest of the pipeline is unaffected.

I think the problem with this approach other than only working with WebApplicationBuilder (which by itself isn't the end of the world), is that someone might call something like UsePathBase or UseRewriter after the CsrfProtectionMiddleware has already run routing and executed all its validation logic on potentially the wrong endpoint, and the CsrfProtectionMiddleware isn't rerun when the routing logic runs again later and matches the correct endpoint. @BrennanConroy Do you have thoughts on this? I know you've dealt with the existing RerouteHelper pattern a bit.

Absent integrating the ICsrfProtection into the endpoint routing middleware itself, I probably would prefer an explicit public UseCsrfProtection() method, but I'd lean towards just integrating it into the routing middleware since it's relatively simple and inexpensive.

Can we not make routing the dumping ground for every other thing? The current design is better and cleaner and allows for future additions to just work.

[DeagleGross]

As agreed offline, following the approach @javiercn suggested. I changed PR name and description to describe that we are not only changing the CSRF middleware mechanics, but auth/authZ as well

[javiercn]

Looks great!