0
votes

Any ASP.NET WebAPI2 ApiController method names that do NOT begin with a configured METHOD prefix (by default Get..., Post..., Put..., Delete..., Head..., Options..., and Patch...) will match an HTTP 'POST'. (See Is there a default verb applied to a Web API ApiController method? for details.)

I would rather have to opt-in for every method, by convention, than opt-out.

To me, the opt-out approach represents a greater security risk, and has no helpful payoff; for consistency, to support POST the implementer should prefix the class method Post... regardless. For example, an ApiController method named SensitiveFunction() shouldn't match any HTTP METHOD unless I intentionally configure support for a 'SENSITIVE' HTTP METHOD.

Is there a simple configuration change that will allow me to disable this POST fallback policy?

Alternately, am I overlooking some reason I would need this fallback policy?

1

1 Answers

0
votes

The default action selection only looks for public instance methods. By making your method public you are effectively "opting in". Scope your methods appropriately with only methods intended to be seen via the API interface as public and everything else private.

http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection

Which methods on the controller are considered "actions"? When selecting an action, the framework only looks at public instance methods on the controller. Also, it excludes "special name" methods (constructors, events, operator overloads, and so forth), and methods inherited from the ApiController class.