# Weaker permission unlocks privileged operation

Check whether move, copy, create, or settings actions enforce the same permission as the privileged action they achieve

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

## How it works
A permission is enforced on the obvious action (delete, create staff, manage users) but not on an adjacent operation that reaches the same end state. The weaker permission becomes a proxy for the stronger one: moving a board out of a workspace removes it just like deleting; writing SMTP settings redirects the reset emails that user management depends on. The assumption that breaks is "gating the named action gates the outcome" — authorization is attached to an endpoint, not to the effect it produces.

## Where it shows up
- Destructive actions (delete, archive, transfer) with sibling operations (move, copy, reassign) that change the same state
- Settings endpoints writable by a lower role: SMTP, webhooks, integrations, notification delivery
- UI-only policy enforcement (owner-only staff creation) with a REST endpoint behind it
- Object-creation endpoints that accept a lower-privileged token and produce objects promotable later
- Fields like `idOrganization`, owner/tenant IDs settable via generic update requests

## How to review
For each privileged outcome, enumerate every operation that produces it and confirm each enforces the same check. The invariant: the permission required to reach an end state must be identical regardless of the path taken (delete vs. move-out; user-create vs. settings-write). Trace where secrets-bearing messages are delivered and who can change that destination. For creation endpoints, ask what the created object can become and whether promotion re-checks the original actor's rights.

## Variants seen
- Move-to-own-workspace bypassing admin-only board deletion [E1](https://bugbountylibrary.com/r/bc%3A598061cf-5339-4684-9fb0-412db75521d1.md)
- Lower-privileged admin creating staff via API despite owner-only UI policy, then promoting via recovery [E2](https://bugbountylibrary.com/r/h1%3A90688.md)
- modify_settings repointing SMTP to capture reset links and credentials [E3](https://bugbountylibrary.com/r/h1%3A2279010.md)

## Why fixes fail
E2 shows a partial model: the UI restricted staff creation but the API did not, and the created object could be promoted through the recovery flow — fixing only the endpoint leaves the promotion path open.

## Impact and severity
Cross-tenant data destruction [E1](https://bugbountylibrary.com/r/bc%3A598061cf-5339-4684-9fb0-412db75521d1.md), full admin takeover from limited admin [E2](https://bugbountylibrary.com/r/h1%3A90688.md), and account takeover of any user including admins [E3](https://bugbountylibrary.com/r/h1%3A2279010.md). Severity rises when the weaker permission is broadly granted and the outcome is irreversible or yields credentials.

## Evidence
- E1: https://bugbountylibrary.com/r/bc%3A598061cf-5339-4684-9fb0-412db75521d1.md
- E2: https://bugbountylibrary.com/r/h1%3A90688.md
- E3: https://bugbountylibrary.com/r/h1%3A2279010.md