Skip to main content
Access controls on a web app are often written against one specific HTTP method, GET being blocked on an admin page, say, while nobody thought to block POST, PUT, or a handful of others on the same endpoint. HTTP Verb Tampering (also called HTTP Method Tampering) is simply trying the methods nobody thought to restrict, often revealing that the “protection” only ever covered one door while leaving several others wide open.

Authentication/Authorization Bypass

A restricted resource is only checked against one method, switching methods skips the check entirely.

Unintended Functionality

Methods like PUT, DELETE, or PATCH expose write/modify capability the developer never meant to leave reachable.

​
Enumerating Allowed Methods

OPTIONS asks the server directly which methods a given endpoint accepts, the fastest way to see what’s actually on the table before trying anything blind.
TRACE (and the older TRACK, a Microsoft IIS-specific variant) echoes the request back verbatim, historically useful for Cross-Site Tracing (XST) attacks against cookies marked HttpOnly, since the reflected request discloses headers JavaScript couldn’t otherwise read.
Most modern servers disable TRACE/TRACK by default specifically because of XST, finding it enabled is itself worth flagging as a finding even before chaining it into anything further.

​
Bypassing a Method-Specific Restriction

If one method is blocked (401/403), try the others, this is the core of the technique and works surprisingly often against access controls bolted on after the fact rather than designed in from the start.
A common root cause on Java-based apps: a web.xml <security-constraint> block that lists a specific <http-method> (commonly GET or POST) is only enforced against that exact method, the Servlet specification treats the listed methods as the entire scope of the constraint. Any verb not explicitly named, PUT, DELETE, HEAD, even a nonstandard custom verb, falls completely outside the restriction and reaches the resource unauthenticated.
Against a config like this, the fix is removing the <http-method> element entirely so the constraint applies to all verbs, which also means: if you see a 403 on GET, always try every other verb before assuming the resource is actually locked down.
HEAD is worth trying specifically when GET is blocked, many frameworks implement HEAD as “run the GET handler, just don’t return the body,” so a blocked GET sometimes still lets HEAD execute the underlying logic (useful for triggering a state change blindly, less useful for reading data since the body won’t come back).

​
X-HTTP-Method-Override

Some frameworks let a client simulate a different verb via a header or parameter, originally meant to work around clients/proxies that can’t send PUT/DELETE directly, but just as usable to route around a filter that only inspects the literal request-line method.
Which header name (if any) a given framework honors varies, try all three above since different stacks pick different conventions.

​
Combining with Header-Based Access Controls

If an application trusts a header like X-Custom-IP-Authorization to decide access (common on internal admin panels that assume only a reverse proxy sets this header), pairing a spoofed local IP with a less-common method can bypass checks that were only written against the standard verb set.
This only works when the backend’s authorization logic is itself verb-specific or incompletely applied, if the IP header check runs identically regardless of method, changing the verb alone won’t bypass it. Confirm the header is actually trusted (test with an obviously wrong IP first) before assuming method tampering is the missing piece.

​
Testing a Full Method Set

Worth cycling through the complete set systematically rather than guessing one at a time, especially against any endpoint that returned a 401/403 on the expected method.
Burp Suite’s Intruder with the method as the payload position (rather than a URL parameter) automates this cleanly, drop the request in, mark the verb, and run the full list in one pass.

​
Quick Reference Tools

Hackviser: HTTP Verb Tampering

Reference used for this page.

OWASP WSTG: Test HTTP Methods

The canonical methodology reference for this test case.
A successful method-tampering bypass against a write/delete-capable endpoint (PUT uploading a file, DELETE removing a resource) is active exploitation, not just enumeration. Confirm scope before going past OPTIONS/HEAD probing.