GET — Error Message Granularity
Focuses on query parameter constraints and resource-aware validation errors under the Error Message Granularity class.
Focuses on query parameter constraints and resource-aware validation errors under the Error Message Granularity class.
400 — Resource-Aware Validation Errors
Vector
Low enumeration risk in isolation, but becomes an oracle when the server validates request parameters against the resolved resource's schema. Different 400 error messages for the same malformed request across different resource IDs reveal that the server looked up the resource before rejecting the request.
Example
GET /api/users/123?fields=ssn HTTP/1.1
Host: target.com
HTTP/1.1 400 Bad Request
{"error":"field 'ssn' is not available for standard users"}
---
GET /api/users/456?fields=ssn HTTP/1.1
Host: target.com
HTTP/1.1 400 Bad Request
{"error":"field 'ssn' is restricted for admin accounts"}Leaking Response / Methodology
- What leaks: Different error messages for the same malformed request reveal that user 123 is a "standard user" and user 456 is an "admin account." The error body leaks resource type/role even though the request was invalid.
- Detection method: Send GET requests with deliberately invalid query parameters across resource IDs. Diff response bodies.
BOLA / IDOR State Leakage
Vector
During Broken Object Level Authorization (BOLA) attempts, returning different error strings for unowned objects compared to missing objects creates an existence oracle.
{"error": "Not found"}(Missing){"error": "Access denied"}(Exists, but belongs to someone else)
Elicitation: Server-Side Parameter Pollution (SSPP)
Mechanism: Injecting duplicate parameters (?fields=a&fields=b) or conflicting URL elements to exploit parsing discrepancies between the router and the controller. The application controller evaluates the parameters against the resource after successfully looking it up.
Isolated Variable: Appending an invalid or duplicate query parameter to an otherwise standard GET request.
Oracle Signal: 400 with a parameter validation error (exists) vs 404 (does not exist).
GET — Existing Resource
GET /api/users/1001?limit=-1 HTTP/1.1
Host: target.comHTTP/1.1 400 Bad Request
Content-Type: application/json
{"error": "limit cannot be negative"}GET — Non-Existing Resource
GET /api/users/9999?limit=-1 HTTP/1.1
Host: target.comHTTP/1.1 404 Not Found
Content-Type: application/json
{"error": "User not found"}Duplicate Parameter Variant — Existing Resource
GET /api/users/1001?fields=email&fields=id HTTP/1.1
Host: target.comHTTP/1.1 400 Bad Request
Content-Type: application/json
{"error": "Duplicate 'fields' parameter detected"}Duplicate Parameter Variant — Non-Existing Resource
GET /api/users/9999?fields=email&fields=id HTTP/1.1
Host: target.comHTTP/1.1 404 Not Found
Content-Type: application/json
{"error": "Not Found"}Mitigation: Enforce query parameter validation constraints globally at the routing layer before looking up the resource.