HTTP Verb Tampering

How HTTP methods work

HTTP servers accept various methods (verbs) at the start of a request and perform different actions depending on which is used. Most developers only consider GET and POST, but clients can send any method — how the server handles unexpected ones determines whether a vulnerability exists.

If a server is configured to accept only GET/POST, an unknown method returns an error page (minor UX/info-disclosure issue, not a critical vulnerability). If the server accepts additional methods without being configured to handle them securely, those methods can be exploited.

HTTP verbs reference

PUT and DELETE in particular can be destructive — writing or removing files in the webroot — if the server is not locked down.

Vulnerability sources

HTTP Verb Tampering vulnerabilities arise from two distinct sources:

Insecure server configuration

Authentication rules scoped to specific methods leave other methods unauthenticated. Example Apache/similar config:

<Limit GET POST>
    Require valid-user
</Limit>

This enforces authentication on GET and POST, but a request using HEAD (or any other unlisted verb) bypasses the rule entirely. An attacker can reach protected pages without credentials.

Insecure coding

Filters or sanitization applied only to one HTTP method while the underlying query uses a broader parameter source. Example PHP:

$pattern = "/^[A-Za-z\s]+$/";

if (preg_match($pattern, $_GET["code"])) {
    $query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
    ...
}

The sanitization check runs against $_GET["code"], but the query uses $_REQUEST["code"] — which includes POST parameters. An attacker sends the payload via POST (leaving GET empty), the filter passes on the empty GET value, and the unsanitized POST value reaches the query. The SQL injection mitigation is bypassed entirely.

Comparison