HTTP Oracles
RFC-compliant HTTP behavior creates exploitable information channels. A series on how status codes, headers, and timing leak state — and when breaking the spec is the right call.
HTTP status codes are designed to be informative. That's exactly what makes them dangerous. Part 1 of a series on how RFC-compliant behavior creates exploitable information channels — and when breaking the spec is the right call.
Different error messages for login, registration, and password reset reveal valid usernames. RFC 9110's semantic distinction between 401 and 403 creates an enumeration surface — the defense is deliberate ambiguity across all credential-checking endpoints.
Response time differences reveal valid users, resources, and internal code paths. The HTTP spec has zero timing requirements — its silence is itself the vulnerability. Defensive implementations must add constraints the RFC never imagined.
Distinct error responses during signature and MAC verification leak cryptographic state. RFC 9457's push for descriptive Problem Details directly conflicts with oracle prevention — the anti-pattern is deliberate error opacity.
JWT's multi-check validation pipeline is an oracle factory — each distinct failure mode for iss, exp, aud, and sig is a bit of leaked state. Granular 401 sub-errors in WWW-Authenticate challenges reveal the exact validation step that failed.
State oracles hide in the HTTP metadata layer — session artifacts, CSRF tokens, rate-limit headers, and caching behavior leak authentication state that response bodies never reveal. Every response header is a potential oracle channel.
Every anti-pattern is a conscious tradeoff. A decision matrix for evaluating HTTP information leakage, the four normalization layers for closing oracle channels, and a prioritized implementation checklist for systematic anti-oracle defense.