Vectors

The existence oracle uses multiple detection vectors — distinct methods of observing the differential. Vectors define what you measure, independent of what you send.

Status-Code-Diff: The direct comparison — does the server return different status codes for existing vs. nonexistent resources? This is the primary vector and covers the majority of existence oracle patterns: 403/404, 200/404, 409/201, 422/404, 410/404, and dozens of others across all HTTP methods.

Cache-Probing: Leveraging conditional request mechanisms — validators (If-None-Match, If-Modified-Since), preconditions (If-Match, If-Unmodified-Since), and range requests (Range, If-Range) — to provoke RFC-mandated responses that differ based on resource existence. A 304 Not Modified response to a conditional GET can only occur if the server found and evaluated an existing representation. A 412 Precondition Failed can only occur if the server reached the precondition evaluation stage. A 416 Range Not Satisfiable can only occur if the server found a representation and attempted to evaluate the range against it. Each of these requires the resource to exist, creating a differential against 404.

Cache-probing is organized in three stages:

• RFC-defined representation evaluation — differentials that are mandated by protocol specifications (304/404, 412/404, 206/404, 416/404).
• Elicitation techniques — specific request manipulations that trigger those RFC-defined differentials (e.g., sending If-None-Match: * to force a 304/404 split).
• Implementation-defined cache behavior — signals created by deployment choices (CDN behavior, negative caching asymmetry, cache-state headers) rather than by protocol specifications.

Error Message Granularity: The body-differential vector — the server returns the same status code for both existing and nonexistent resources, but the response body differs based on whether the resource was found. This occurs because the server resolves the target resource before evaluating the request constraints: when the resource exists, validation errors are resource-aware ("field 'ssn' is not available for standard users"); when it doesn't, the server short-circuits to a generic failure before reaching validation. The differential is in the body, not the status code.

EMG operates across all HTTP methods:

• GET — query parameter constraint errors and BOLA state leakage (400 with resource-typed error vs 404)
• POST — creation constraint and relationship conflict messages (409/400 body content differs based on resource state)
• PUT/PATCH — schema validation errors reference the existing resource's field types (422 body reveals resource shape)
• DELETE — state constraint violations (foreign key messages, lock violations) that only occur on existing resources (409/403 body content)

GET /api/users/123?fields=restricted HTTP/1.1        → 400 {"error":"field not permitted for standard users"}
GET /api/users/999?fields=restricted HTTP/1.1        → 404 Not Found

Unlike Status-Code-Diff, EMG requires body diffing to detect — the status codes are identical or overlapping. Unlike Cache-Probing, it does not depend on conditional request mechanics; it emerges from the server's normal validation pipeline executing against a resolved resource.

Future vectors include header-diff (comparing response header sets) and timing analysis (measuring response latency distributions). The analysis pipeline is designed so that all vectors run against every probe pair regardless of which strategy generated it — a probe designed for status-code-diff may also surface EMG signals or cache-probing signals from the same response.