PUT / PATCH — Error Message Granularity

Focuses on schema validation and type coercion under the Error Message Granularity class.

422 / 400 — Type Confusion & Schema Validation

Vector

Sending incomplete payloads, missing required fields, or wrong data types (e.g., arrays instead of strings) to see if the server resolves the ID before validating the payload structure.

Example

PATCH /api/users/123 HTTP/1.1
Host: target.com
{"email": ["invalid_type"]}

HTTP/1.1 400 Bad Request
{"error": "Invalid type for field 'email', expected string"}

---

PATCH /api/users/999 HTTP/1.1
Host: target.com
{"email": ["invalid_type"]}

HTTP/1.1 404 Not Found
{"error": "User not found"}

Leaking Response / Methodology

• What leaks: The server checks if the user exists before it validates the JSON payload schema. The existence of the resource is confirmed because the schema validation error ("Invalid type for field") is only evaluated if the resource lookup succeeds.
• Detection method: Send intentionally malformed payloads (wrong types, missing fields) to existing and non-existing IDs and monitor if the schema validation error is returned instead of a 404.

Elicitation: Schema Fuzzing

Destructive

Mechanism: The server resolves the resource before evaluating the payload structure against the resource's schema. By deliberately omitting required fields or sending invalid types, the schema validator will throw an error (400 or 422) if the resource exists. If it doesn't exist, the router returns a 404 before the body is ever parsed.

Isolated Variable: The JSON payload structure is valid, but the type of a single field is incompatible with the expected schema.

Oracle Signal: 400 / 422 with a schema validation error (exists) vs 404 (does not exist).

PUT — Existing Resource

PUT /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 17

{"email": ["a"]}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid type for field 'email', expected string"}

PUT — Non-Existing Resource

PUT /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 17

{"email": ["a"]}

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "User not found"}

PATCH — Existing Resource

PATCH /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 21

{"email": ["invalid_type"]}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid type for field 'email', expected string"}

PATCH — Non-Existing Resource

PATCH /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 21

{"email": ["invalid_type"]}

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "Not Found"}

Mitigation: Perform resource existence checks and return a 404 before parsing and validating the request body schema.

Elicitation: Content-Type Mismatches & Payload Truncation

Destructive

Mechanism: Sending intentionally truncated payloads to trigger parsing layers. If the application routes the URL before parsing the body, a syntactically invalid body will throw a parse error for existing IDs, but a 404 for missing ones.

Isolated Variable: A truncated JSON body that violates JSON syntax.

Oracle Signal: 400 with a parser exception (exists) vs 404 (does not exist).

PUT — Existing Resource

PUT /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 10

{"name": "

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "SyntaxError: Unexpected end of JSON input"}

PUT — Non-Existing Resource

PUT /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 10

{"name": "

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "User not found"}

Mitigation: Move request payload parsing to a global middleware layer that runs before route resolution.