HTTP Verb Tampering — Bypassing Basic Authentication

Exploiting insecure server configuration verb tampering is straightforward: try alternate HTTP methods and observe how the server handles them. Automated scanners catch this type reliably (auth bypass is obvious once it works), but miss the insecure-coding variant, which requires active testing.

Identify

1. Find a page or directory that returns an HTTP Basic Auth prompt (401).
2. Confirm the scope of the restriction — does the whole /admin directory require auth, or just a specific endpoint? Visit the parent directory to check.
3. Note the HTTP method the protected action uses (typically GET).

Exploit

Step 1 — try the obvious alternative

Intercept the request in Burp Suite. If the action uses GET, switch to POST (right-click → Change Request Method). Forward and check whether the 401 still appears.

If POST is also blocked, the config covers both — move to step 2.

Step 2 — enumerate accepted methods

Use OPTIONS to see what the server actually allows:

curl -i -X OPTIONS http://TARGET/

Example response:

HTTP/1.1 200 OK
Allow: POST,OPTIONS,HEAD,GET

Step 3 — try HEAD

HEAD is identical to GET but returns no response body. It is accepted by default on many web servers and is frequently not included in auth restrictions that only list GET and POST.

Change the intercepted request method to HEAD and forward. Expected results:

• No login prompt
• No 401
• Empty response body (normal for HEAD)
• The server-side action still executes (e.g., files deleted, state changed)

Key point

The absence of output is not failure — HEAD suppresses the body by design. Verify the action took effect by checking application state rather than looking for response content.

Takeaway

Any HTTP method not explicitly covered by an auth rule is a potential bypass. Always test HEAD first (near-universal support, no body to raise suspicion), then work through the full OPTIONS list.