Add option to disable form field as CSRF token source from `AntiforgeryOptions`

[MaceWindu]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Related to one of issues discussed here #18087

We use CSRF token from headers and have custom file upload middleware.

For it we don't want to have current behavior when call to IAntiforgery.IsRequestValidAsync drains request body stream if there is no token header, which makes stream unusable for custom form parser and consume a lot of resources on big uploads for nothing. For similar reason we don't want to move CSRF check to form parse code - it complicates parse logic and results in a lot of discarded work (especially if you already saved received file body to file system/database) if validation fails (perfect example where fail fast behavior is a must)

Describe the solution you'd like

// AntiforgeryOptions.cs
public bool SuppressTokenFromForm { get; set; } // or whatever name you like

Additional context

related code?

if (requestToken.Count == 0 && httpContext.Request.HasFormContentType)

// proposed change
if (requestToken.Count == 0 && httpContext.Request.HasFormContentType && !_options.SuppressTokenFromForm)

Summary Comment : #51912 (comment)

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

@MaceWindu thanks for contacting us.

The asks sound reasonable and it's also a potential area for new contributors, so I am going to fill in the details for that as part of the process the team has. We will provide a proposal that more or less matches our expectations of what the change should look like.

If you are interested in contributing the change, we are happy if you want to take it over from the proposal or if you have an alternative proposal for a different change (or want to discuss any details) we can do it here.

[javiercn]

Issue Summary

There is no way to suppress the body check for the request Antiforgery token. This can potentially cause an app to read the request body in search for the Antiforgery token when it's not present on the header, which has an impact on performance.

Potential Design

There are several pivots here:

• We can have a global option on the AntiforgeryOptions type, which makes the change apply everywhere.
• We can have a per-endpoint option via some metadata inside RequireAntiforgeryTokenAttribute

I'm more inclined to go with the RequireAntiforgeryAttribute approach, as it lets us be more granular and doesn't impact other areas in the system. (MVC/Components) where this change won't make sense.

• We might need a global option still for elements that are not endpoint aware. In that situation endpoint wins over global option.
  • That means changes in the global option don't impact MVC or Components as they can set this option in metadata.

As per the values, I think an Enum makes sense here Header, FormBody, HeaderOrFormBody with a default of HeaderOrFormBody.

• We will update RequireAntiforgeryTokenAttribute to include an optional RequestTokenSource property.
• We will update the logic on DefaultAntiforgery to account from the source coming either from the options or the endpoint metadata.
• We will add the relevant tests to DefaultAntiforgeryTest.

Important Considerations

• This change will have to go through the API review process for any new public API that we add.
• We will have to make sure it doesn't negatively impact Blazor Web or MVC.

Additional Notes

• If the change you are going to make will include a public API change in the framework, then the change will need to go through our API Review Process. Please read this process to take any necessary steps, to avoid any potential delays down the road with accepting this change.
• If this is your first contribution to the repo, you may find it useful to learn How to build the repo
• Please note, that the changes will be considered for the vNext version of the framework by default. That is, after the change gets merged in main, it will be available only in the next preview release of the framework and will be shipped in the upcoming major release of the product.