Home / Knowledge hub / HTTP verb tampering
Knowledge hub
HTTP verb tampering
Switching a request's method to reach a path that only checks other methods.
What it means
Every web request carries a method, or verb: GET to read, POST to submit, PUT or DELETE to change things. HTTP verb tampering means sending a different method from the one the application expected, hoping a security rule only covers the common ones.
The classic case is an access rule written for GET and POST only. A request using another method, such as HEAD or a made-up one, is not matched by the rule, so the server skips the check but still runs the action.
Why it matters
The result is a control that looks present and is not. An admin page protected for two methods can be reached with a third. A delete that needs approval through the browser can be sent as a plain API call. Nothing is cracked; the check was simply never asked.
It is a good example of broken access control. Rules that list what to block fail the moment someone finds a case you did not list. Rules that start from deny by default do not. The gap is easy to miss because the page behaves normally for everyone using the usual methods.
How it shows up
You meet it in older Java web configuration, where a security constraint names only certain methods, and in gateways, proxies and frameworks with route rules per method. Method override headers such as X-HTTP-Method-Override are another route, because they let a POST be treated as a DELETE.
Check what each path does with every method, including OPTIONS, HEAD and unusual ones. Apply the authorisation check to the action itself, not to a list of verbs. Switch off method override unless you truly need it, and refuse methods the route does not support.
Questions people ask
HTTP verb tampering, answered
Which HTTP methods should be allowed?
Only the ones each route really needs. A read-only page needs GET, and perhaps HEAD. Everything else should return a clear error such as 405.
An allowlist of methods per route is easier to reason about than a blocklist.
Is HEAD a risk?
HEAD is meant to behave like GET without a body. Some frameworks route it to the GET handler, so the action may run even though the response is empty.
Make sure your access check runs for it too.
What is a method override header?
It is a request header that asks the server to treat one method as another, often so browsers or proxies that only send GET and POST can still reach other actions.
If you do not need it, turn it off.
Does a WAF stop verb tampering?
It can block unusual methods, but it cannot know which method each of your routes expects. The application still has to enforce its own rules.
Treat a WAF as a second layer.
How do we test for it?
Send each protected path with every method, signed in and signed out, and compare the answers. A page that says no to GET and yes to something else is the finding.
Include the override headers in the test.
Sources
Where this comes from
Related
Terms that sit next to this one
Broken access control
An application failing to enforce its own rules about who may do what.
Deny by default
Refusing every request unless a rule explicitly allows it.
Missing function-level access control
A sensitive action that checks you are signed in but not whether you may use it.
Forced browsing
Typing the address of a page you were never linked to and finding it opens.
API authentication
How an API decides which caller is making a request before it does anything.
Does the check cover every method?
We try paths with the methods your rules did not list and show the exact request that got through. A fix is proven by replaying that same request. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.