HEAD

Status code differentials observed via HEAD requests. All strategies in this section are Safe risk tier — read-only probing with no state mutation. HEAD requests return no body, making them ideal for high-volume enumeration with minimal bandwidth.

Elicitation Strategies

204 vs 404

Vector

Server returns 204 No Content for existing resources with no representation body (common on HEAD requests, DELETE confirmations, or empty sub-resource endpoints) vs 404 for nonexistent resources. The 204 confirms existence even with an empty body — the status code alone is the signal. Bandwidth-efficient for large-scale enumeration.

Example

HEAD /api/users/123/avatar HTTP/1.1
Host: target.com

HTTP/1.1 204 No Content
ETag: "abc123"

---

HEAD /api/users/999/avatar HTTP/1.1
Host: target.com

HTTP/1.1 404 Not Found

Leaking Response / Methodology

• What leaks: 204 vs 404 confirms user 123 exists (and has an avatar resource slot, even if empty). The ETag header on 204 is an additional signal — it confirms the resource is cacheable and has a version. Common on sub-resource endpoints (avatars, preferences, settings) where the parent resource exists but the sub-resource has no content yet.

Cross-Method Oracles

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

414 vs 404

Vector

Per RFC 9110 §15.5.15, a server returns 414 URI Too Long when the request URI exceeds a configured limit. If the limit check occurs after routing resolves the resource, existing resources trigger 414 while nonexistent ones return 404. HEAD is ideal for this probe — no body in either direction, minimal bandwidth.

Example

HEAD /api/users/123?padding=AAAAAAA...AAAA HTTP/1.1
Host: target.com

HTTP/1.1 414 URI Too Long

---

HEAD /api/users/999?padding=AAAAAAA...AAAA HTTP/1.1
Host: target.com

HTTP/1.1 404 Not Found
```http

#### Leaking Response / Methodology

- **What leaks:** 414 vs 404 confirms user 123 exists. The server resolved the resource before evaluating the URI length limit.