Methodology
How parlov detects information leakage through RFC-compliant server behavior.
parlov detects information leakage by observing how HTTP servers behave correctly and measuring whether that correct behavior reveals protected internal state to unauthorized observers. The server is not broken. The leak is the protocol working as specified.
The foundation is always a differential — two inputs, two responses, one conclusion. A single response in isolation proves nothing. Every oracle parlov detects is built on the difference between how a server responds to a known-valid input versus an unknown or suspect one.
What this section covers
The Differential Principle
Why a single response is never enough. The two-input model that underlies every oracle class: baseline vs probe. How ProbeSet encodes this contract in code.
RFC Compliance as the Source
The counterintuitive premise: oracles exist because servers implement RFCs correctly. Specific examples from RFC 9110, RFC 7235, RFC 6750, and RFC 5789.
Auth Contexts
Every oracle must be evaluated from three distinct perspectives. The same endpoint can have an oracle in one context and none in another.
Vectors
The HTTP method axis used to probe the same resource. GET, HEAD, POST, PATCH, PUT, and DELETE each create distinct oracle surfaces.
Elicitation
How probes are structured to maximize oracle signal. The YAML probe definition format, key practices, and how required_samples drives the scheduler.
The Scan Pipeline
Code orchestration from input to verdict. The four stages, workspace layout, crate boundaries, and the Probe and Analyzer traits.
Signal Scoring
The confidence and severity model — base anchors, normative weighting, signal families, corroboration bonuses, verdict thresholds, and why confidence and severity are separate axes.