# Hidden parameter authorization bypass

Client-set flags or bracketed field names that change which account is resolved or skip an auth check

_Area: Web access control and IDOR. Seen in 3 disclosed reports; 2 confirmed bounties: $10,000 and $20,000; latest 2025-03-13. Updated 2026-10-23._

## How it works
Authorization is decided on one view of the request, but the handler acts on another. A hidden boolean flag or a bracketed field name is parsed by the backend after a proxy or middleware has already validated a different representation. The check passes on the sanitized view; the handler then trusts the attacker-supplied view. The broken assumption: the validated request and the executed request are the same object.

## Where it shows up
- Boolean flags in request bodies that gate identity resolution or visibility (skip_customer_creation, includeSuspended) [E1](https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md)[E3](https://bugbountylibrary.com/r/h1%3A1018336.md)
- Field names with brackets or nested-query syntax (`[file]`) crossing a signing proxy boundary [E2](https://bugbountylibrary.com/r/h1%3A850447.md)
- Endpoints accepting multiple encodings (ProtoJson vs JSON) where validation covers only one [E1](https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md)
- Handlers that re-parse a signed field name with a different parser than the signer used [E2](https://bugbountylibrary.com/r/h1%3A850447.md)

## How to review
Trace the exact bytes the authorizer validates versus the bytes the handler consumes. The invariant: every field that influences authorization or identity lookup must be either server-derived or covered by the same signature/validation the handler relies on. Concretely: does the handler re-parse the request with a different parser than the validator? Does any client-supplied flag change which account is resolved? Does a bracketed or nested field name collapse to nil under one parser while attacker params win under another? If yes to any, treat as unsafe until proven otherwise.

## Variants seen
- Hidden visibility flag on a read endpoint leaking linked-account IDs and private emails [E1](https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md)
- Bracketed field name `[file]` collapsing to nil under parse_nested_query, passing the signed-field presence check while attacker-supplied `file.path` wins in the handler [E2](https://bugbountylibrary.com/r/h1%3A850447.md)
- Client flag flipped to force email-to-customer resolution, returning the matched customer's full name [E3](https://bugbountylibrary.com/r/h1%3A1018336.md)

## Why fixes fail
E2 was found while reviewing the patch for a prior workhorse bypass: the fix validated the signed field name but still parsed it with parse_nested_query, so a bracketed name collapsed to nil and passed. Validating presence of a key is not the same as validating its parsed value.

## Impact and severity
High: cross-tenant PII disclosure (creator emails, customer full names) and file read within allowed upload paths, including other users' in-flight uploads via /proc/PID/fd [E1](https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md)[E2](https://bugbountylibrary.com/r/h1%3A850447.md)[E3](https://bugbountylibrary.com/r/h1%3A1018336.md). Severity rises when the leak is an oracle (email in, PII out) enabling enumeration, and when debug errors expose the hidden parameter surface that makes the bypass discoverable [E1](https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md).

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Abrutecat-com-articles-youtube-creator-emails.md
- E2: https://bugbountylibrary.com/r/h1%3A850447.md
- E3: https://bugbountylibrary.com/r/h1%3A1018336.md