HTTP Verb Tampering is a technique where an attacker changes the HTTP method to reach functionality that should not be exposed. For example, a blocked action may still be reachable through a different verb if controls only inspect one method. Defenders should enforce authorisation per action, not per verb, and test all supported methods.
How HTTP Verb Tampering Works
HTTP verb tampering exploits a mismatch between the HTTP method a client sends and the method a server or security control expects. If an application protects an action by checking only one verb, an attacker may reach the same function through another supported verb and bypass the intended restriction.
This matters because the verb itself is not the security boundary. A blocked web application attack pattern can still succeed when the backend routes, middleware, or framework handlers accept alternative methods such as GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS.
Why It Becomes Dangerous
Verb tampering is most dangerous when access control is tied to request shape rather than to the action being performed. A developer may intend one method for a feature, but the application stack may expose the same route through multiple methods, hidden framework behaviours, or inconsistent authorization checks across layers.
The result is often unintended functionality exposure, especially where administrative actions, state-changing operations, or sensitive workflows are reachable through a method that was not validated as strictly as the primary one. That is why defenders should treat every supported method as part of the attack surface, not just the one documented in the UI or API specification.
How to Check Exposure
Exposure checks should begin with inventorying routes and enumerating which methods each endpoint actually accepts in practice. Testing should include direct requests, proxy replay, automated fuzzing, and review of framework defaults so that hidden or alternate methods are not missed.
Security teams should also compare route behaviour with authorization policy, because verb tampering usually shows up as a control mismatch rather than a pure coding error. If a control only blocks one method, or if reverse proxies and application logic disagree on how a request should be handled, the application may be more exposed than its documentation suggests.
For broader attack-path context, MITRE ATT&CK Enterprise is useful when method tampering is part of a larger exploitation chain that leads to privilege escalation or unauthorized action.
Remediation and Testing Guidance
Remediation should focus on authorizing the action itself, not the HTTP verb that happened to carry it. If a feature should be unavailable to a user or role, every method that can reach that feature must be governed by the same authorization decision.
In practice, this means testing all supported methods during development, regression testing after framework changes, and validating that middleware, routing rules, and application handlers all enforce the same policy. A defence-in-depth review of request handling is especially important where APIs or mixed web frameworks expose overlapping endpoints.
For API-oriented environments, the OWASP API Security Top 10 is a useful companion reference because verb tampering often sits near broken authorization and inconsistent object or function access control. When method handling is part of a broader identity and access model, NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the need for consistent authorization, logging, and configuration control across the stack.
Risk and Threat Considerations
HTTP verb tampering can turn a seemingly blocked function into a reachable one, especially when the control plane and the application disagree about which methods are allowed. The risk is not limited to exposure of a single endpoint, because one inconsistent handler can undermine trust in the surrounding access model.
Failure mechanism: A defender filters or authorizes only one verb, but the application still accepts an alternate method that reaches the same code path or a related privileged action.
Impact: Attackers may perform unauthorized state changes, invoke hidden functionality, or bypass a control that was assumed to protect the endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Verb tampering bypasses function-level access checks on alternate methods. |
| Recommendation — Enforce the same authorization decision for every method that reaches a function. | ||
| MITRE ATT&CK | T1211 — Exploit Public-Facing Application | HTTP verb tampering is a public-facing application exploitation pattern. |
| Recommendation — Hunt for alternate-method abuse on exposed application endpoints. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Access must be enforced on the action, not only on a single HTTP verb. |
| CM-6 — Configuration Settings | Consistent method handling depends on secure routing and control configuration. | |
| Recommendation — Apply access enforcement to the protected action across all request methods. Standardize and verify method handling settings across application components. | ||
Practitioner Guidance
Why practitioners should care: Verb-level controls are fragile unless they are backed by action-level authorization. If a feature matters enough to protect, every method that can invoke it should be tested and governed as part of the same security decision.
Common misunderstanding: Seeing one blocked request does not prove the endpoint is protected. A passing method through the same route, proxy, or framework handler may still expose the function if the policy is inconsistent.