A pattern worth naming properly, because I keep seeing it reported as two separate low-severity findings instead of one real issue.
Whenever a request passes through more than one component that interprets structure - a proxy and an origin, a gateway and a service, a validator and a consumer - each one parses independently. If they disagree about where a boundary is, security decisions made by the first component do not apply to what the second one actually processes.
Neither parser is wrong on its own terms. That is exactly why this survives review: each team can look at its own component, find it standards-compliant, and close the ticket. The finding only exists in the gap.
How to look for it without weaponising anything:
- •Enumerate every component in the request path that makes a decision based on structure - routing, authorisation, caching, logging.
- •For each pair, find the inputs where their specifications permit different readings. Ambiguity in the spec is the leading indicator.
- •Send an inert input that would be read differently and observe which reading each component logged. You are looking for two components describing the same request differently. That divergence is the whole finding.
- •Stop there and report it. You do not need to reach impact to prove a disagreement exists, and reaching for it is how a methodology post turns into something I would not publish.
The tell in the wild: the access log and the application log disagree about what was requested. If you can get a program to check that once, they usually find it themselves.