PUT

Status code differentials observed via PUT requests. All strategies in this section are MethodDestructive risk tier — non-idempotent methods that may have side effects but avoid permanent data loss.

Elicitation Strategies

200 / 204 vs 404

Vector

Server returns 200 OK or 204 No Content for a successful PUT request against an existing resource. If the server does not allow resource creation via PUT at the target URI, a nonexistent resource fails at routing/resolution and returns 404 Not Found.

Example

PUT /api/users/123 HTTP/1.1
Host: target.com
Content-Type: application/json
{"name":"alice","role":"viewer"}

HTTP/1.1 200 OK
Content-Length: 44
{"id":123,"name":"alice","role":"viewer"}

---

PUT /api/users/999 HTTP/1.1
Host: target.com
Content-Type: application/json
{"name":"bob","role":"viewer"}

HTTP/1.1 404 Not Found
Content-Length: 27
{"error":"user not found"}

Leaking Response / Methodology

• What leaks: 200/204 vs 404 confirms user 123 exists. A 200 response may also leak the newly modified representation of the resource.

409 vs 201

Vector

Server evaluates the current state of an existing resource against a valid PUT request and returns 409 Conflict due to a constraint violation (e.g., conflicting If-Match, version mismatch, or schema constraints per RFC 9110 §9.3.4). A nonexistent resource is successfully created and returns 201 Created. The differential between a state conflict and a successful creation confirms the resource already exists.

Example

PUT /api/users/123 HTTP/1.1
Host: target.com
Content-Type: application/json
If-Match: "invalid-etag"
{"name":"alice","role":"viewer"}

HTTP/1.1 409 Conflict
Content-Length: 58
{"error":"conflict","detail":"etag mismatch for user 123"}

---

PUT /api/users/999 HTTP/1.1
Host: target.com
Content-Type: application/json
If-Match: "invalid-etag"
{"name":"bob","role":"viewer"}

HTTP/1.1 201 Created
Content-Length: 42
{"id":999,"name":"bob","role":"viewer"}

Leaking Response / Methodology

• What leaks: 409 vs 201 confirms user 123 exists. The 409 body leaks details about the resource's current schema or state constraints.

Shared PATCH / PUT Oracles

The following oracles apply equally to both PATCH and PUT requests. Full details and examples are documented on the PATCH page — they are summarized here for completeness.

422 vs 404

Server validates the request body against the existing resource's schema and returns 422 Unprocessable Entity for validation errors, but 404 for nonexistent resources. The validation error implies the resource was found — the server only validates input against a resource that exists. This is a two-for-one oracle: existence confirmation plus schema enumeration.

• What leaks: 422 vs 404 confirms existence. The 422 body leaks the resource's schema — valid enum values, field constraints, type requirements. Each different invalid payload reveals a different constraint.

415 vs 404

Payload negotiation failure. Sending a request with an obscure Content-Type causes an existing endpoint/resource to fail parsing and return 415 Unsupported Media Type. Nonexistent resources return 404 before payload parsing occurs.

• What leaks: 415 vs 404 confirms existence. The 415 indicates the server resolved the resource and attempted to process the request body.

412 vs 404

State-conditional requests using If-Match: "invalid-etag" or If-Unmodified-Since. The server checks the precondition against the actual state of an existing resource, failing with 412 Precondition Failed. If the resource is missing, it returns 404.

• What leaks: 412 vs 404 confirms existence. The 412 indicates the server evaluated the resource's current state against the precondition.

413 vs 404

Per RFC 9110 §15.5.14, a server returns 413 Content Too Large when the request body exceeds a size limit enforced after resolving the resource. Existing resources trigger 413; nonexistent ones return 404.

• What leaks: 413 vs 404 confirms existence. The server resolved the resource before checking body size.

411 vs 404

Per RFC 9110 §15.5.12, a server returns 411 Length Required when Content-Length is missing. If the check occurs after resource resolution, existing resources trigger 411; nonexistent ones return 404.

• What leaks: 411 vs 404 confirms existence. Low-noise probe — omitting a single header is unlikely to trigger WAF rules.