# Hidden-field search and API leakage

Search indexes and API responses exposing fields that visibility rules hide from normal reads

_Area: Web access control and IDOR. Seen in 2 disclosed reports; latest 2023-10-25. Updated 2026-10-23._

## How it works
A visibility rule is applied in one place but the same data is reachable through another path that never learned the rule. The assumption that breaks is "if the UI hides it, the backend won't reveal it." Two shapes appear: a search index matches against the full record including hidden portions, so a match/no-match answer leaks the hidden content; and an API (often GraphQL, often for a different client) returns raw stored fields while the UI shows a fuzzed or filtered version. In both cases the hidden value is not returned directly but is observable through a side channel: existence of a match, or a more precise value than intended.

## Where to show up
- New search features layered over content with partial-visibility rules (limited disclosure, private fields, redacted bodies).
- GraphQL responses whose raw JSON is more specific than the rendered page (exact coordinates, full postcode, internal IDs).
- Multiple clients (web vs mobile) hitting the same data with different serializers.
- Server-side rounding or fuzzing of sensitive values before return.
- Fields present in the response but not displayed by any UI.

## How to review
The invariant: every read path enforces the same visibility boundary as the most restrictive display. For search, confirm the index is built only from fields the requester may see, or that match results are filtered by the same rule as the rendered record. For APIs, diff raw responses against what the UI shows and confirm fuzzing/rounding happens server-side before serialization, not in one client. For rounded values, ask whether the rounding boundary is itself an oracle: if a sensitive value is rounded, the flip point between two rounded outputs can be probed to recover the pre-rounding value. Treat any deterministic function of a secret as a leak channel.

## Variants seen
- Search index matching hidden report body, leaking existence of secret words [E2](https://bugbountylibrary.com/r/h1%3A2213251.md).
- GraphQL advert response returning exact lat/long and full postcode to unauthenticated users, bypassing UI fuzzing [E3](https://bugbountylibrary.com/r/blog%3A7elements-co-uk-resources-blog-facebooks-burglary-shopping-list.md).
- Server-rounded distance whose rounding boundary enables trilateration to ~5m [E1](https://bugbountylibrary.com/r/h1%3A1234406.md).

## Impact and severity
Leaked precise location (to ~5m) enabling physical targeting [E1](https://bugbountylibrary.com/r/h1%3A1234406.md); exposure of non-public report content via brute-force [E2](https://bugbountylibrary.com/r/h1%3A2213251.md); exact seller location to unauthenticated users [E3](https://bugbountylibrary.com/r/blog%3A7elements-co-uk-resources-blog-facebooks-burglary-shopping-list.md). Severity rises when the leak is unauthenticated, repeatable at scale, and concerns physical safety or confidential report content. Side-channel leaks are worse because they look like normal, intended output.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A1234406.md
- E2: https://bugbountylibrary.com/r/h1%3A2213251.md
- E3: https://bugbountylibrary.com/r/blog%3A7elements-co-uk-resources-blog-facebooks-burglary-shopping-list.md