POST

Status code differentials observed via POST requests. All strategies in this section are MethodDestructive risk tier — non-idempotent methods that may create resources or trigger side effects.

Elicitation Strategies

409 vs 2xx / 303

Vector

Creation endpoints return 409 Conflict when a resource already exists, but accept the request when it doesn't. Depending on the server's creation pattern, a nonexistent resource triggers a success/redirect response:

• 201 Created: Standard synchronous creation.
• 200 OK: Creation where the response describes the action's result.
• 202 Accepted: Asynchronous creation where the request is queued for processing.
• 204 No Content: Creation succeeds but the server has no body to return.
• 303 See Other: Creation redirects to the new resource.

All of these vs 409 create a binary existence oracle. The classic email enumeration pattern — POST /signup with an existing email gets 409, a novel email succeeds. Any create-if-not-exists endpoint is vulnerable. OWASP WSTG-IDNT-04 specifically calls out this vector.

Example

POST /api/users HTTP/1.1
Host: target.com
Content-Type: application/json
{"email":"alice@corp.com","password":"test123"}

HTTP/1.1 409 Conflict
Content-Length: 48
{"error":"conflict","detail":"email already exists"}

---

POST /api/users HTTP/1.1
Host: target.com
Content-Type: application/json
{"email":"nonexistent@corp.com","password":"test123"}

HTTP/1.1 201 Created
Content-Length: 65
{"id":456,"email":"nonexistent@corp.com"}

Leaking Response / Methodology

• What leaks: 409 vs 2xx/303 confirms alice@corp.com is a registered user. The 409 body often leaks which field conflicted (email, username, phone). Even if the server normalizes to a generic error message, the status code alone is the oracle. Auth0, HackerOne report #666722, and countless bug bounties confirm this is the most common account enumeration vector.

Cross-Method Oracles

The following oracles are not POST-specific but are observable via POST requests.

413 vs 404

Vector

Per RFC 9110 §15.5.14, a server returns 413 Content Too Large when the request body exceeds a size limit. If the limit is enforced after resolving the target resource (per-resource or per-endpoint limits), existing parent resources trigger 413 while nonexistent ones return 404 before size validation occurs.

Example

POST /api/users/123/documents HTTP/1.1
Host: target.com
Content-Type: application/octet-stream
Content-Length: 52428800

<50 MB payload>

HTTP/1.1 413 Content Too Large

---

POST /api/users/999/documents HTTP/1.1
Host: target.com
Content-Type: application/octet-stream
Content-Length: 52428800

<50 MB payload>

HTTP/1.1 404 Not Found
{"error":"user not found"}
```http

#### Leaking Response / Methodology

- **What leaks:** 413 vs 404 confirms user 123 exists. The server resolved the parent resource and reached its size-limit check. The 413 response may include `Retry-After` or limit details that reveal per-resource quotas.

### 411 vs 404

#### Vector

Per RFC 9110 §15.5.12, a server returns 411 Length Required when the request lacks a `Content-Length` header and the server refuses to accept the request without one. If the server checks this *after* resolving the resource, existing resources trigger 411 while nonexistent ones return 404.

#### Example

```jsx
POST /api/users/123/actions HTTP/1.1
Host: target.com
Content-Type: application/json
Transfer-Encoding: chunked

7
{"a":1}
0

HTTP/1.1 411 Length Required

---

POST /api/users/999/actions HTTP/1.1
Host: target.com
Content-Type: application/json
Transfer-Encoding: chunked

7
{"a":1}
0

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

Leaking Response / Methodology

• What leaks: 411 vs 404 confirms user 123 exists. The server resolved the resource before checking for Content-Length. This is a low-noise probe — omitting a single header is unlikely to trigger WAF rules or anomaly detection.