# File reference widens visibility policy

Inline file references or content URIs that re-grant access without rechecking the viewer's permission

_Area: Web access control and IDOR. Seen in 2 disclosed reports; 2 confirmed bounties: $500 and $2,000; latest 2022-07-29. Updated 2026-10-23._

## How it works
A file carries a view policy (who may see it). When that file is referenced elsewhere — an inline `{F<id>}` marker, a `content://` URI, a copied attachment — the system must decide whether the new context grants access. The broken assumption is that referencing an object is permission-neutral. In practice, some rendering or edit path re-applies the *editor's* or *context's* permissions to the referenced file, silently widening its view policy. The file's own policy is never rechecked against the new audience.

## Where it shows up
- Inline object-reference syntax (file IDs, embeds, mentions) rendered in posts, tasks, comments, commit messages, imports.
- Edit flows that touch content containing a reference and may propagate the editor's rights to the referenced object.
- Multiple rendering paths for the same markup (object attachment vs. commit message vs. comment) with differing checks.
- Android multi-user storage: parallel `content://<user>@media/...` namespaces (e.g. user 150 for Secure Folder/work profiles) resolved by browsers or content providers.
- Content providers/browsers that don't enforce profile lock state on cross-user media.

## How to review
The invariant: **a reference never changes a file's view policy, and every rendering path enforces the same view-permission check against the actual viewer.** Check that:
- Rendering a reference verifies the *viewer* can view the file, not the author/editor.
- Editing content with a reference does not silently widen the file's policy; any widening is explicit and confirmed.
- All paths using the same markup (attachments, commit messages, comments, imports) share one enforcement point.
- Cross-profile URIs are gated on lock state, not just namespace reachability.

## Variants seen
- Editing a post containing a private file reference re-grants public access when a privileged user edits it [E1](https://bugbountylibrary.com/r/h1%3A763177.md).
- Commit-message file-attach syntax parsed without a view check, unlike normal attachment, letting restricted files become public [E3](https://bugbountylibrary.com/r/h1%3A1560717.md).
- Secure Folder files reachable via `content://150@...` URIs in the browser while locked, enumerable and exfiltratable [E2](https://bugbountylibrary.com/r/blog%3Aservicenger-com-blog-mobile-sve-2020-18025-unauthorised-access-to-samsung-secure-folder-files.md).

## Impact and severity
Private file disclosure across users, roles, or tenants; in E2, locked Secure Folder contents exposed. Severity rises when enumeration is easy (predictable IDs, script onload/onerror probing) and when the widened access is silent and persistent. Median bounty ~$2000 reflects reliable confidentiality impact.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A763177.md
- E2: https://bugbountylibrary.com/r/blog%3Aservicenger-com-blog-mobile-sve-2020-18025-unauthorised-access-to-samsung-secure-folder-files.md
- E3: https://bugbountylibrary.com/r/h1%3A1560717.md