Document antiforgery skip in AntiforgeryMiddleware for DELETE via HttpMethodOverride

[cincuranet]

This is not a common combination of pieces, but should be properly documented anyway. Maybe Roslyn analyzer could help here as well.

1. Server developer added HttpMethodOverrideMiddleware (which is not default).
2. Configured with form field mode (FormFieldName set) - header mode triggers CORS preflight and is not cross-origin exploitable.
3. Method override registered before antiforgery in the pipeline.
4. Target endpoint uses antiforgery.
5. The endpoint accepts DELETE (or another non-POST/PUT/PATCH method).

We can explicitly document that AntiforgeryMiddleware and extensions like app.UseAntiforgery() only support checking a subset of methods (POST, PUT and PATCH), and if user needs other HTTP methods validated, they can resolve IAntifogery and validate the request explicitly.

[github-actions]

Triage Summary

Area: area-security — The issue is about AntiforgeryMiddleware behavior (antiforgery token validation) and HttpMethodOverrideMiddleware interaction, both falling under the security/antiforgery area.
Type: docs — The reporter is requesting documentation (and possibly a Roslyn analyzer) to clarify that AntiforgeryMiddleware/UseAntiforgery() only validates POST, PUT, and PATCH by design. No code bug is described.

Potential Duplicates

• None found

Notes

• The issue already carries a Docs label, which is consistent with the content.
• The described behavior (antiforgery only checking POST/PUT/PATCH) appears intentional by design; the request is for better documentation of that fact and the pitfall when HttpMethodOverrideMiddleware is in the pipeline with form-field mode.
• The suggestion to add a Roslyn analyzer as a secondary option could be tracked as a separate feature-request or api-proposal if the team decides to pursue it.

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66687 · ● 153.5K · ◷