Document CORS AllowCredentials requirement for Fetch-Metadata CSRF trust - #37660
Draft
DeagleGross wants to merge 4 commits into
Draft
DeagleGross wants to merge 4 commits into
DeagleGross wants to merge 4 commits into
Conversation
Contributes to dotnet/aspnetcore#69345 - security/anti-request-forgery.md: the automatic CSRF protection middleware's "How it works" and "Allowing cross-origin clients" sections now state that a CORS-allowed origin only grants CSRF trust when the policy also calls .AllowCredentials(). Updated the CORS code sample to include .AllowCredentials() so it stays a correct example, and added a short note next to the existing AllowAnyOrigin warning. - migration/100-to-110/includes/security.md: one-line update to the CORS guidance bullet to mention the new AllowCredentials() requirement. - breaking-changes/11/csrf-cors-allowcredentials-required.md: new breaking-change entry describing the behavior change, following the existing template. Registered in overview.md and toc.yml. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Per feedback: the AllowCredentials() requirement for CORS-derived CSRF trust is unreleased (dotnet/aspnetcore#69345 is still open), so it shouldn't be documented as a breaking change or a 10->11 migration concern yet. - Removed breaking-changes/11/csrf-cors-allowcredentials-required.md - Reverted the registration in breaking-changes/11/overview.md and toc.yml - Reverted the migration/100-to-110/includes/security.md CORS bullet - Removed the breaking-change cross-link from anti-request-forgery.md, keeping the AllowCredentials() requirement description, updated CORS code sample, and AllowAnyOrigin note Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
# Conflicts: # aspnetcore/security/anti-request-forgery.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contributes to dotnet/aspnetcore#69345
Summary
dotnet/aspnetcore#69345 ("Align Fetch-Metadata CSRF trust with CORS credentials intent") changes
DefaultCsrfProtectionso that a CORS-allowed origin only counts as CSRF-trusted when the resolved CORS policy also has.AllowCredentials()configured (policy.SupportsCredentials). Previously, any non-AllowAnyOriginpolicy that trusted the request's origin was enough.Note: dotnet/aspnetcore#69345 is still open at the time of this PR, targeting
release/11.0. Opening this docs PR as draft, consistent with the precedent set by #37262 - it can be marked ready once the aspnetcore PR merges. Since the feature hasn't shipped yet, this PR only updates the conceptual doc; it doesn't add a breaking-change entry or 10-to-11 migration note.Why
CORS's
AllowCredentials()is the explicit flag a developer sets to mean "this cross-origin caller may act on behalf of the signed-in user (send/receive cookies)." A policy that only callsWithOrigins()without.AllowCredentials()means "this origin can call me anonymously," which isn't the trust relationship CSRF protection is about. Requiring the credentials flag aligns CSRF trust with what the CORS configuration actually authorizes.AllowAnyOriginremains excluded from CSRF trust either way (unchanged).Files changed
aspnetcore/security/anti-request-forgery.md- updated the "How it works" rule and the "Allowing cross-origin clients" section of the automatic CSRF protection docs to state the new.AllowCredentials()requirement, with a short rationale. Updated the CORS code sample to include.AllowCredentials()so it stays a correct example. Added a short note next to the existingAllowAnyOriginwarning about named-origin policies needing.AllowCredentials()for CSRF trust.Not changed
aspnetcore/security/cors.md- documents CORS itself, not CSRF trust derivation; doesn't mention CSRF today, so left untouched per scope.Internal previews
Build report