HTTP Verb Tampering

What is HTTP Verb Tampering?

HTTP Verb Tampering (also called HTTP Method Tampering) is an attack technique where an attacker manipulates the HTTP method of a request to bypass authentication and authorization mechanisms.

The HTTP protocol knows various methods (verbs) that clients use to communicate with servers:

• GET: Retrieve resources
• POST: Send data to the server (e.g., forms)
• PUT: Update or create resources
• DELETE: Delete resources
• HEAD: Like GET, but only headers without body
• OPTIONS: Shows supported methods for a resource
• TRACE: Echo request for debugging (often disabled)
• PATCH: Partial update of a resource

While most web applications only actively use GET and POST, many servers also accept other methods – often without this being explicitly intended or secured.

The problem: Many access control mechanisms only protect the most common methods. A simple example from a Java EE configuration:

<security-constraint>
  <web-resource-collection>
    <url-pattern>/admin/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>

This configuration only protects /admin/* for GET and POST. A HEAD request? Goes through. A PUT request? Also uncontrolled. The attacker has free rein.

How Does the Attack Work?

The process is remarkably simple:

1. Reconnaissance: The attacker identifies a protected endpoint (e.g., /admin/users)
2. Testing: They try various HTTP methods – HEAD, OPTIONS, PUT, DELETE, or even invented methods like MPRV
3. Exploitation: If they find a method that isn't blocked, they can bypass access control

Manipulating the HTTP method is trivial. With a proxy tool like Burp Suite or OWASP ZAP, any request can be intercepted and modified:

Original Request:
POST /admin/delete-user HTTP/1.1
Host: vulnerable-app.com
Cookie: session=xyz123

Manipulated Request:
HEAD /admin/delete-user HTTP/1.1
Host: vulnerable-app.com
Cookie: session=xyz123

If the server doesn't explicitly block HEAD requests, this request could go through – even if authentication fails for POST.

Real Attack Scenarios

Scenario 1: Admin Panel Access

A web application protects the admin panel under /admin/. The protection is configured as follows:

• GET /admin/ → Authentication required ✅
• POST /admin/ → Authentication required ✅
• HEAD /admin/ → No protection defined ❌

An attacker sends a HEAD request and gains access. Since HEAD functions technically identical to GET (just without the response body), they can extract information or even trigger actions if the server doesn't prevent side effects on HEAD.

Scenario 2: Data Manipulation via PUT

A blog application allows users to edit their own posts:

• POST /blog/create → Create new article
• PUT /blog/edit/123 → Edit article 123 (own article only)
• DELETE /blog/delete/123 → Delete article 123

The access control correctly checks for POST and PUT whether the user is the owner of the article. But for DELETE, this check is missing – presumably because the developer assumed that DELETE would be triggered via a form with POST anyway.

An attacker sends a direct DELETE /blog/delete/456 request and deletes other users' articles. Verb Tampering combined with Missing Function Level Access Control – a fatal combination.

Scenario 3: Apache/PHP Default Handling

Some servers treat unknown HTTP methods like standard methods. An attacker sends:

FOOBAR /admin/config HTTP/1.1
Host: vulnerable-app.com

If the Apache server is configured to accept unknown methods, it might treat them like GET. The access control only checks explicitly defined methods – FOOBAR isn't among them. Bingo: access without authentication.

Particularly Dangerous HTTP Methods

HEAD – The Underestimated Twin of GET

HEAD is functionally identical to GET, but only returns HTTP headers, no body. This makes it popular for availability checks.

Problem: Many developers forget that HEAD triggers the same server-side processes as GET. If access control only protects GET, HEAD is a bypass.

OPTIONS – Information Leak

OPTIONS shows which HTTP methods are available for a resource. This is actually harmless – but can give attackers valuable hints:

OPTIONS /admin/users HTTP/1.1
Host: vulnerable-app.com

Response:
Allow: GET, POST, PUT, DELETE, HEAD, OPTIONS

Now the attacker knows that PUT and DELETE exist – and can specifically test whether they are protected.

TRACE – Cross-Site Tracing (XST)

TRACE was originally developed for debugging. The server simply echoes back the entire request. This sounds harmless, but it isn't:

• Attackers can use TRACE to read HttpOnly cookies (Cross-Site Tracing)
• Combined with XSS, TRACE becomes a cookie-stealing weapon

Best Practice: TRACE should always be disabled.

PUT and DELETE – Data Manipulation

These methods are powerful – and precisely therefore dangerous when accessible without control. PUT can upload files, DELETE can remove resources. Without strict authentication, a security disaster.

Why is HTTP Verb Tampering So Common?

The vulnerability is well-known, OWASP has listed it for years. Why does it still occur regularly?

1. Lack of Awareness

Many developers think in terms of GET and POST. That there are nine standardized HTTP methods (plus arbitrary custom methods) is unknown to many.

2. Framework Defaults Are Insecure

Many frameworks allow all HTTP methods by default unless explicitly restricted. "Secure by Default" looks different.

3. Incomplete Configurations

Developers define access control rules for GET and POST – and overlook that the rule therefore only applies to these methods. What isn't explicitly protected is open.

4. Testing Gaps

Standard security tests usually only check standard methods. HTTP Verb Tampering requires explicit fuzzing with different verbs – few do this.

Protection Measures: How to Prevent HTTP Verb Tampering?

1. Define Explicitly Allowed Methods (Whitelist Approach)

Instead of trying to block all dangerous methods (blacklist), explicitly define which methods are allowed per endpoint.

Example for Apache:

<Location /admin>
  <LimitExcept GET POST>
    Require all denied
  </LimitExcept>
</Location>

This means: Only GET and POST are allowed. All other methods (HEAD, PUT, DELETE, etc.) are blocked.

2. Globally Disable Unnecessary Methods

If your application exclusively uses GET and POST, block everything else at the server level.

Example for Nginx:

if ($request_method !~ ^(GET|POST)$ ) {
  return 405;
}

Example for Apache (global):

<Directory /var/www>
  <LimitExcept GET POST>
    Require all denied
  </LimitExcept>
</Directory>

3. Use Framework-Specific Access Control

Modern web frameworks often offer built-in mechanisms that automatically cover all HTTP methods.

Example for Spring Security (Java):

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated();
}

This rule applies to all HTTP methods – no Verb Tampering possible.

4. Disable TRACE Method

TRACE is almost never used legitimately and poses security risks. Disable it:

Apache:

TraceEnable off

Nginx:

if ($request_method = TRACE) {
  return 405;
}

5. Deploy Web Application Firewall (WAF)

A WAF can automatically block suspicious HTTP methods. Modern WAFs learn which methods your application actually uses and block everything else.

6. Regular Penetration Testing

Automated vulnerability scanners often miss HTTP Verb Tampering. Manual pentests with targeted method fuzzing uncover such gaps.

Checklist: Is Your Application Vulnerable?

Test yourself whether HTTP Verb Tampering poses a risk:

• ❓ Are access control rules defined only for GET and POST?
• ❓ Does your server accept HEAD requests on protected resources?
• ❓ Can you see via OPTIONS which methods are available?
• ❓ Is TRACE enabled?
• ❓ Does the server accept arbitrary custom methods (e.g., FOOBAR)?
• ❓ Does your application distinguish between different HTTP methods for the same URL?
• ❓ Are there REST APIs that use PUT/DELETE but have no explicit authentication for them?

If you answer even one question with "yes", you should take a closer look.

HTTP Verb Tampering in the Context of Modern Architectures

REST APIs and Microservices

RESTful APIs use HTTP methods semantically:

• GET /users → Retrieve list
• POST /users → Create new user
• PUT /users/123 → Update user 123
• DELETE /users/123 → Delete user 123

This is elegant – but only secure if each method is individually authorized. A common mistake: GET is open (read-only), POST/PUT/DELETE require admin rights – but the check only applies to POST, not to PUT/DELETE.

Single Page Applications (SPAs)

SPAs often communicate exclusively via AJAX with REST backends. Developers assume that the JavaScript code only uses defined methods. But an attacker bypasses the SPA and sends requests directly – with any methods.

Conclusion: Frontend controls don't protect. Backend validation is mandatory.

Conclusion: Underestimated but Dangerous

HTTP Verb Tampering is not a spectacular zero-day vulnerability. It's a configuration gap resulting from lack of awareness and incomplete security controls. But the impacts can be severe:

• Unauthorized access to admin functions
• Data manipulation or deletion
• Bypassing authentication and authorization

The good news: Protection is simple. A whitelist approach, explicit method controls, and regular testing are usually enough to eliminate the vulnerability.

The bad news: As long as developers think in terms of "GET and POST" and forget that HTTP knows nine standard methods (plus arbitrary custom methods), HTTP Verb Tampering will continue to be found in the wild.

Time to change that. Check your applications. Secure your endpoints. And remember: What isn't explicitly protected is open.