---
name: web-authorization-workflows
description: Investigate object/tenant authorization, role and grant transitions, workflow ordering, stale state and bounded race candidates using isolated owned actors and authoritative state checks. Use on a specific application operation, not as a bulk IDOR scan.
---

# Authorization and workflow specialist

Locally curated from primary application-security research and testing guidance; see
[research-cases.md](references/research-cases.md). This is not an upstream author's released skill.

## Model the business operation

Map actors, owned objects, grants/inheritance, roles, states, and the valuable operation. Cite the
intended permission or workflow rule. Capture ordinary behavior through the current browser/Burp
integration. Bind each request to an isolated principal, including every credential-bearing header,
cookie and capability. Do not copy the owner's authority into the supposed attacker request.

Choose one concrete boundary:

| Boundary | Focus |
| --- | --- |
| Object or tenant | Same operation on A's equivalent object versus B's private object; use only known owned IDs. |
| Function or role | Which server operation a lower role can execute, including side effects and inherited grants. |
| Grant transition | New access, removal, revocation and legitimate propagation; check the authoritative resource. |
| Representation | Read/export/preview/attachment/API paths that should enforce the same resource permission. |
| Workflow state | Required steps, retry/idempotency, cancel/complete, callback ordering and stale references. |
| Concurrency | A named shared-state collision and a final-state invariant; start with serial controls. |

Use three comparable observations where applicable: B can operate on B's object; A can perform the
feature on A's object; A's treatment on B's object exceeds its intended permission. For a distinct
bypass mechanism, compare with and without that mechanism. Record how IDs could be learned in reality.

## Proof requirements

Verify the precise synthetic content, state change, privilege or recipient outcome. Similar response
lengths, a 200, an error-free UI, or different JSON sizes are not authorization proof. Do not increment
IDs or enumerate third-party objects. Show that the resource is not public, shared or authorized by
another credential, prior grant, capability, or parent container.

A timing anomaly is a lead. Bound any concurrency experiment to the program and disposable fixtures;
verify the final result and count successes/valid trials. Never infer a race from an uncompleted UI
action. Keep live account work serial except for the explicitly designed, bounded concurrency test.

Output the operation/actor/state matrix, violated rule, actual principal binding, controls, observed
effect, causal factor, remaining alternative, and cleanup. Apply fp-check before reporting.