Some APIs accept an X-HTTP-Method-Override header (or a _method form field) so a POST can be treated as PUT, PATCH or DELETE. When is that justified, and what risks does it introduce?

## What the mechanism is Method override lets a client that can only issue certain HTTP methods reach handlers bound to others. Two common encodings: ``` POST /orders/42 HTTP/1.1 X-HTTP-Method-Override: DELETE ``` or, from an HTML form: ``` POST /orders/42 Content-Type: application/x-www-form-urlencoded _method=DELETE ``` A filter early in the server pipeline reads the override and rewrites the request method, so routing and the application see `DELETE`. ## Why it exists **HTML forms.** The form element supports only GET and POST. Server-rendered applications that want RESTful routes for update and delete have used `_method` for decades; several frameworks ship it built in. **Hostile intermediaries.** Some corporate proxies, older load balancers and a few WAF configurations block or strip PUT, PATCH and DELETE — historically because those methods were associated with WebDAV. A client behind one cannot reach your endpoints at all. **Constrained clients.** Old SDKs, embedded HTTP stacks, or a partner's integration platform that only exposes GET and POST. Outside those, it is not justified. A modern browser `fetch`, a mobile app, or any server-side HTTP client can send any method, and using override there just obscures what the code does. ## The security problem Everything between the client and your handler makes decisions using the method on the request line. Once the effective method differs, those decisions are made about the wrong operation. **Gateway and WAF policy.** A rule like "DELETE is only allowed for the admin path" or "this route is read-only" inspects the request line, sees POST, and lets it through. The application then deletes. This is the classic method-override bypass, and it is real: teams put method restrictions at the edge precisely because they trust the edge, and override silently invalidates that. **Method-based authorization in the app.** Frameworks let you express rules per method. If the authorization filter runs *before* the override filter, the rule is evaluated against POST while the handler performs a DELETE. Ordering is the whole ballgame: normalization must happen before any security decision, and that ordering must be tested, not assumed. **Override on GET.** Some implementations honour the header on any method. If `GET /orders/42` with an override header performs a delete, you have re-created the state-changing-GET vulnerability with an extra step — and CSRF protection typically exempts GET entirely. Never honour the override on a safe method. **Observability and audit.** Access logs, metrics and traces record POST. Working out that a resource was deleted requires correlating a header nobody logs by default. In an incident, that costs time. **Caching.** POST responses are not cached, so this is mostly benign, but intermediaries reasoning about safety and idempotency now have wrong information — a proxy will not retry what it thinks is a POST even though the operation is an idempotent PUT, and conversely will not treat it as unsafe when it should. ## If you must support it 1. **Only on POST.** Reject or ignore the header on GET, HEAD and OPTIONS. 2. **Allowlist the target methods** — PUT, PATCH, DELETE. Do not allow arbitrary strings, and certainly not GET (which would let an attacker turn a protected write route into a read of something else). 3. **Normalize first.** Run the override filter before authentication, authorization, CSRF and rate limiting, so every downstream decision sees the effective method. 4. **Scope it.** Enable only on the routes or client groups that genuinely need it, ideally gated by an API key or a specific path prefix, rather than globally. 5. **Log both** the wire method and the effective method, and make sure metrics and audit records use the effective one. 6. **Keep the edge in sync.** If your gateway enforces method policy, it must apply the same normalization, or its rules are decorative. 7. **Retire it.** Track which clients still need it and remove support when they are gone — it is a compatibility shim with an expiry date. ## Alternatives Before adding it, check whether the blockage is real: often the "proxy strips PATCH" story is folklore. If only creation and updates are affected, exposing a POST-based action endpoint (`POST /orders/42/cancel`) is more honest than tunnelling DELETE, because the wire method then matches what actually happens. And CORS preflight failures — a common reason PATCH "does not work" from a browser — are fixed by configuring `Access-Control-Allow-Methods`, not by tunnelling.