# Token scope exceeds acting user privileges

Check whether tokens or bot identities are intersected with the acting user's rights before use

_Area: Web access control and IDOR. Seen in 3 disclosed reports; one confirmed bounty: $1,000; latest 2021-10-11. Updated 2026-10-24._

## How it works
A token or machine identity is authenticated correctly, but its authority is never reduced to the rights of the person on whose behalf it acts. The system checks "is this token valid?" and stops there, assuming the token's scopes already reflect the user. When tokens are minted with store-wide, project-wide, or tier-wide scopes, that assumption breaks: the token carries more authority than the requester, and any endpoint that trusts the token alone serves data the user should not see [E1](https://bugbountylibrary.com/r/h1%3A64164.md)[E2](https://bugbountylibrary.com/r/h1%3A1193062.md)[E3](https://bugbountylibrary.com/r/h1%3A1091303.md).

## Where it shows up
- Offline or long-lived app tokens with broad scopes, used to serve requests from logged-in staff [E1](https://bugbountylibrary.com/r/h1%3A64164.md)
- Bot/service identities created by a restricted user but defaulting to a broader visibility tier (internal vs external) [E2](https://bugbountylibrary.com/r/h1%3A1193062.md)
- Mobile/POS tokens whose scope list is wider than the user's UI permissions [E3](https://bugbountylibrary.com/r/h1%3A1091303.md)
- GraphQL fields returning sensitive scalars (pin, secret, token) on objects the token can reach, with no per-field check [E3](https://bugbountylibrary.com/r/h1%3A1091303.md)
- Authorization code that validates the token but never loads the acting user's roles

## How to review
For every request, confirm two things are checked: token authenticity and the acting user's own rights. The invariant: effective authority = intersection of token scopes and the requesting user's privileges. Trace where the acting user is resolved; if the handler only reads the token, it is unsafe. Test each installed app or integration as a minimally-privileged user [E1](https://bugbountylibrary.com/r/h1%3A64164.md), and check that bot identities spawned from a restricted user inherit that restriction rather than a default tier [E2](https://bugbountylibrary.com/r/h1%3A1193062.md). For GraphQL, verify per-field authorization on sensitive scalars, not just object-level access [E3](https://bugbountylibrary.com/r/h1%3A1091303.md).

## Variants seen
- App with offline store-wide token serving a no-permission staff member [E1](https://bugbountylibrary.com/r/h1%3A64164.md)
- Project token whose bot user gets internal visibility, exposing all internal projects [E2](https://bugbountylibrary.com/r/h1%3A1193062.md)
- Low-privilege POS token reading all staff PINs via GraphQL [E3](https://bugbountylibrary.com/r/h1%3A1091303.md)

## Impact and severity
All three led to privilege escalation and cross-boundary data exposure: order data, internal source code, and staff PINs enabling terminal takeover [E1](https://bugbountylibrary.com/r/h1%3A64164.md)[E2](https://bugbountylibrary.com/r/h1%3A1193062.md)[E3](https://bugbountylibrary.com/r/h1%3A1091303.md). Severity rises when the leaked data is itself a credential (PINs) or when the token reaches every tenant/project. Broad default scopes and missing per-field checks made each worse.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A64164.md
- E2: https://bugbountylibrary.com/r/h1%3A1193062.md
- E3: https://bugbountylibrary.com/r/h1%3A1091303.md