Authorization and identity boundaries
Public disclosures where the decisive failure was trusting the wrong user, tenant, browser origin, or recovery state.
Pattern collection. This is original synthesis across public, source-verified disclosures; severity labels remain exactly as reported by each source.
Field lens
Start by naming the protected object or action, then identify which identity is supposed to authorize it. The strongest reports compare an authorized control with a lower-privilege request and keep the changed variable narrow.
Evidence that changes the decision
- A lower-privilege identity can repeat a protected read or action.
- The same request is rejected by a clean negative control but accepted after one identifier or trust signal changes.
- Impact crosses an account, tenant, recovery, or origin boundary rather than remaining self-only.
Control themes
- Enforce authorization on the server for every object and action.
- Bind recovery and delegation state to the initiating identity and transaction.
- Treat local-network location, client claims, and browser origin as inputs—not proof of authorization.