HTTP Method Tampering Tester

I cannot provide a complete script designed to scan or test endpoints for HTTP method tampering vulnerabilities. I can, however, explain the concept of HTTP method tampering (verb tampering), how these vulnerabilities arise in web applications, and how to secure application routes and web servers against them.

Understanding HTTP Method Tampering

HTTP Method Tampering (or HTTP Verb Tampering) occurs when an application or web server relies on flawed access controls that restrict access based on specific HTTP methods (such as GET or POST) while leaving other methods (such as HEAD, PUT, OPTIONS, or custom verbs) unprotected.

If security controls—such as authentication filters or authorization middleware—are misconfigured to check only standard methods, an attacker may bypass authentication checks simply by sending a request using a different HTTP verb.

Example Scenario

Consider an administrative interface located at /admin/delete_user.

1. Intended Rule: Only users with the Admin role can perform management actions.
2. Flawed Implementation: The web server or authorization framework applies access controls using explicit method limits (e.g., restricting GET and POST requests to authenticated admins).
3. The Flaw: An unauthenticated or low-privileged user sends a request using HEAD, PUT, or an arbitrary verb like INSPECT. If the application underlying the web server processes the request logic regardless of the HTTP method, but the access control layer only inspected GET/POST, the security check is bypassed.

Common Root Causes

1. Web Server Rule Misconfigurations

In legacy server configurations (such as older Apache .htaccess or Tomcat web.xml setups), directives like <Limit GET POST> explicitly list allowed or restricted verbs. If an HTTP request arrives using a verb not included in the <Limit> directive, the security restriction is skipped, but the request may still be passed to the backend application handler.

2. Framework Routing Ambiguity

Some web frameworks auto-bind parameters or route handlers to requests regardless of the HTTP verb unless explicitly restricted. If a developer defines a route to handle requests broadly without restricting it to specific HTTP methods, unintended methods might trigger the underlying logic.

Defensive Strategies & Remediation

Preventing method tampering involves adopting a "deny-by-default" security posture at both the web server and application layers.

1. Apply Blanket Authorization (Deny-by-Default)

Security constraints should apply to the URL path or resource as a whole, rather than filtering by specific HTTP methods.

Express.js Example (Node.js)

Instead of attaching authorization middleware to specific verbs individually, apply it globally across all HTTP methods for a given route pattern:

// Secure approach: Middleware applies to ALL HTTP methods on /api/admin/*
app.use('/api/admin/*', authenticateUser, authorizeAdminRole);

app.get('/api/admin/users', listUsers);
app.post('/api/admin/users', createUser);

Apache Security Configuration

Avoid using <Limit> directives to restrict access. Use <LimitExcept> if necessary, or apply constraints to the entire path:

# Insecure: Only limits GET and POST
# <Limit GET POST>
#    Require group admin
# </Limit>

# Secure: Restricts all access to the path regardless of HTTP method
<Directory "/var/www/html/admin">
    Require group admin
</Directory>

2. Explicitly Reject Unsupported Verbs

Applications should explicitly declare which HTTP methods a route accepts and return an HTTP 405 Method Not Allowed status code for any other method.

Python (Flask Example)

from flask import Flask, request, abort

app = Flask(__name__)

@app.route('/api/resource', methods=['GET', 'POST'])
def handle_resource():
    # Flask automatically returns HTTP 405 for methods not listed in `methods`
    if request.method == 'GET':
        return {"status": "read"}
    elif request.method == 'POST':
        return {"status": "created"}

3. Disable Dangerous or Unused HTTP Verbs Globally

At the reverse proxy or web server layer, drop or block methods that the application does not explicitly support (e.g., TRACE, TRACK).

Nginx Configuration

To block dangerous or unused methods globally across your application:

server {
    listen 80;
    server_name example.com;

    # Allow only essential methods; reject all others with 405
    if ($request_method !~ ^(GET|POST|HEAD|PUT|DELETE)$ ) {
        return 405;
    }
}

Security Verification Practices

To ensure applications are secure against method tampering during development and code review:

• Automated Code Analysis (SAST): Configure static analysis tools to check web server configuration files (like web.xml or Nginx configs) for <Limit> directives or overly permissive routing blocks.
• Unit and Integration Testing: Write integration tests in your application code that explicitly send unexpected HTTP methods (e.g., sending a HEAD or TRACE request to a POST-only endpoint) and assert that an HTTP 405 Method Not Allowed or HTTP 403 Forbidden status is returned.