-
Baseline the real verbs
For each sensitive route, record allowed methods without override: OPTIONS/Allow,
and responses for GET, HEAD, POST, PUT, PATCH, DELETE. Capture status,
length, body hash, and auth context (anonymous / low-priv / admin).
-
Inventory override surfaces (one channel per trial):
| Channel | Examples |
|---|
| Headers | X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override |
| Query | ?_method=DELETE, ?method=PUT |
| Body (form) | _method=PATCH with application/x-www-form-urlencoded |
| Body (JSON) | {"_method":"DELETE"} only if stack documents it |
| Nested | Override header and _method with conflicting verbs |
Prefer values: PUT, PATCH, DELETE, HEAD, OPTIONS, and invalid tokens
(FOO, empty, lowercase delete) to map parse rules.
-
Spoof past wire-method gates
Send an allowed outer method the edge permits, with override toward a privileged
action the edge would block if sent natively:
POST /api/users/123 HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
X-HTTP-Method-Override: DELETE
_method=DELETE
Also try outer GET with ?_method=POST or override header (CSRF / SameSite path):
GET /account/email?email=attacker@evil.test&_method=POST HTTP/1.1
Host: target.example
Success = privileged side effect or body matching the blocked native verb, not
only a different error page.
-
WAF / gateway vs origin split
Compare native DELETE (often 403/405 at edge) vs POST + override (200/204 at
origin). Log which hop denied (Server, Via, WAF headers). Edge-only fool without
origin executing the verb is a config gap; full impact needs origin applying override
after authz that trusted the outer method.
-
Auth middleware ordering
Hypothesis: middleware enforces “POST-only CSRF” or “no DELETE for role X” on the
request-line method; router later rewrites to DELETE/PUT. Tests:
- Low-priv session: outer POST (allowed) + override DELETE on admin resource.
- CSRF token present/absent only on outer POST while effective verb is DELETE.
- PUT requires auth natively, but
POST + _method=PUT succeeds under weaker policy.
Prove with two accounts or a canary you own; avoid mass deletes.
-
CSRF implications
If cookies authenticate and override turns navigable GET into a state change,
build an authorized PoC (test victim only):
<script>
location = "https://target.example/settings?email=pwned@evil.test&_method=POST";
</script>
Cross-check SameSite, Referer, and tokens under csrf-cross-site-request-forgery.
Bearer-only APIs without cookies are usually CSRF-N/A — still note override for
BOLA/ACL if middleware is verb-bound.
-
Framework notes (measure, do not assume)
Rails/Laravel: _method on POST forms. Some Java filters honor
X-HTTP-Method-Override only for POST. ASP.NET may use X-HTTP-Method-Override or
X-Method-Override. Field names vary (_method, method, _METHOD). Confirm with
response differentials, not blog claims.
-
Remediation
Authorize on the effective method after one canonical parse; disable override on
sensitive APIs; if needed for HTML forms, allowlist POST→PUT/PATCH/DELETE only, ignore
overrides on GET, apply CSRF/authz to the effective verb; align WAF; add role-matrix tests.
