REST verb confusion

Why This Matters

HTTP method confusion and verb override attacks have been documented in real-world penetration tests and bug bounty reports across banking, healthcare, and e-commerce platforms. In 2019, a researcher demonstrated on a major travel booking platform that a GET request with the X-HTTP-Method-Override: DELETE header successfully deleted bookings belonging to other users — the DELETE route was unprotected because developers assumed it would only be reachable via actual DELETE requests, and the access control middleware was mapped to HTTP methods, not to override header values. OWASP Testing Guide OTG-CONFIG-006 specifically addresses HTTP method testing, and Broken Function Level Authorization (API5:2023) covers the failure to enforce authorization consistently across all request methods that trigger the same server-side function.

Core Concept

HTTP method override is a convention introduced to work around environments (corporate proxies, older browsers, some firewalls) that permit only GET and POST. When a server honours override headers or parameters, a client sends a POST request but includes a header or body field that instructs the server to treat the request as a different HTTP method.

Common override mechanisms: - X-HTTP-Method-Override: DELETE — widely supported by Rails, Django REST Framework, and Express with method-override middleware. - X-Method-Override: PATCH — used by some Java and .NET implementations. - _method=PUT in an application/x-www-form-urlencoded POST body — the original Rails convention, inherited by Laravel, Symfony, and others.

The access-control bypass arises from a routing/middleware mismatch: the framework routes the request based on the effective method (after override), but the authorization middleware is registered on the original HTTP verb. If the admin checks if (req.method === 'DELETE') requireAdmin() but the override happens before the method is rewritten, the check fires on POST and passes, while the handler executes DELETE logic.

HTTP verb enumeration via the OPTIONS method returns an Allow response header listing the methods the endpoint accepts (Allow: GET, POST, PUT, DELETE, PATCH). This confirms the attack surface before attempting method confusion.

HEAD requests are an often-overlooked vector: a HEAD request returns only response headers (no body) but may execute the same handler as GET. If a GET handler checks authorization and returns data in the body, a HEAD request may pass through a WAF or access control that does not recognise HEAD as a data-retrieval verb.

Technical Deep-Dive

-- Step 1: Enumerate accepted methods
OPTIONS /api/admin/users HTTP/1.1
Host: victim.com
Authorization: Bearer <low_priv_token>

HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS
-- DELETE is listed; test whether ACL is enforced on actual DELETE vs override

-- Step 2: Direct DELETE attempt (blocked by ACL)
DELETE /api/admin/users/99 HTTP/1.1
Host: victim.com
Authorization: Bearer <low_priv_token>

HTTP/1.1 403 Forbidden
{"error":"Admin role required"}

-- Step 3: Override bypass via header (POST treated as DELETE by framework)
POST /api/admin/users/99 HTTP/1.1
Host: victim.com
Authorization: Bearer <low_priv_token>
X-HTTP-Method-Override: DELETE
Content-Length: 0

HTTP/1.1 200 OK
{"message":"User 99 deleted"}
-- ACL checked req.method == 'POST' (passed), handler executed DELETE logic

-- Step 4: Override bypass via _method parameter
POST /api/admin/users/99 HTTP/1.1
Host: victim.com
Authorization: Bearer <low_priv_token>
Content-Type: application/x-www-form-urlencoded

_method=DELETE

# Automated method testing with curl across all standard verbs
for method in GET POST PUT PATCH DELETE HEAD TRACE CONNECT OPTIONS; do
  echo -n "$method: "
  curl -s -o /dev/null -w "%{http_code}" 
    -X "$method" https://victim.com/api/admin/users 
    -H "Authorization: Bearer <low_priv_token>"
  echo
done

Security Assessment Methodology

1. Send OPTIONS to each interesting endpoint — Record the Allow header to confirm which methods the server claims to support. Note discrepancies between the Allow header and application documentation.
2. Test each listed method directly — Verify that non-GET methods are properly restricted to authorized users. Use Burp Repeater, changing only the HTTP method between requests.
3. Test method override headers — For each restricted method (DELETE, PUT, PATCH), send a POST request with X-HTTP-Method-Override: <METHOD> and X-Method-Override: <METHOD>. Compare the response with the direct method test.
4. Test _method parameter — Send a POST with application/x-www-form-urlencoded body containing _method=DELETE (and other methods).
5. Test HEAD requests on GET-protected endpoints — A HEAD to a URL that requires authorization for GET may bypass the check if the authorization middleware only triggers on GET or POST.
6. Use Burp Autorize configured with a low-privilege token to automatically replay all requests with method overrides and highlight authorization bypasses.
7. Check TRACE and CONNECT — Though rarely exploitable in modern environments, TRACE can reflect HTTP headers (including Authorization) back in the response body if enabled, facilitating cross-site tracing (XST) attacks.

Defensive Countermeasure — Apply authorization middleware based on the intended operation rather than the raw HTTP verb. If method override is required for compatibility, rewrite the effective method before the authorization layer runs — never after. Disable X-HTTP-Method-Override and _method support entirely if the application does not serve environments that require it. Configure the web server to reject TRACE and CONNECT globally.

Common Assessment Errors

• Only testing GET and POST — The access control gaps are on the less-common verbs (DELETE, PATCH, PUT); focus enumeration there, not on the verbs the developer certainly tested.
• Forgetting HEAD — HEAD is semantically a GET without a response body; many WAFs and ACL rules explicitly list GET and POST but omit HEAD, leaving HEAD as an unchecked path.
• Not testing override in both header and body form — A server may only implement one override mechanism; test X-HTTP-Method-Override header, X-Method-Override header, and _method body parameter separately.
• Assuming OPTIONS response is authoritative — The Allow header reflects what the framework router accepts, not what is secured; an endpoint may handle a method without listing it in OPTIONS, or list a method it rejects.
• Missing method override on non-admin endpoints — Verb confusion is equally exploitable on user-scoped endpoints where the ACL differs by verb (e.g., GET is allowed, PUT is restricted to account owners).
• Not checking JSONP endpoints — JSONP callbacks are often mounted only on GET but a method override may trigger the JSONP handler via POST, bypassing CSRF protections designed for GET.

NICE Framework Alignment

Further Reading

• OWASP Testing Guide v4.2 — OTG-CONFIG-006: Test HTTP Methods — OWASP Foundation
• OWASP API Security Top 10 — API5:2023 Broken Function Level Authorization — OWASP Foundation
• The Web Application Hacker's Handbook, 2nd ed. — Stuttard & Pinto, Wiley
• HTTP/1.1 Semantics and Content — RFC 7231 — IETF (Fielding & Reschke)