Object authorization and workflow access control

Mechanism

Authentication identifies a caller; authorization decides whether that caller may perform a particular action on a particular object. Insecure direct object references often arise when handlers trust an object identifier without checking ownership or scope. Authorization errors also occur across workflow transitions, such as approving an item before its required validation step.

Practical method

Create two lab identities with different objects and roles. Capture a valid read and write request for each, then substitute only the object identifier or action. Test list, detail, export, and bulk endpoints independently. For workflows, map allowed states and replay a transition from an earlier state while observing the server record rather than only the user interface.

allow = caller.has_permission(action)
        AND object.tenant_id == caller.tenant_id
        AND transition_allowed(object.state, action)

Interpreting evidence

A hidden button is not a server-side access decision. Confirm whether the object was returned or changed, and whether the response leaks only metadata or full content. Keep the two identities and their ownership boundaries explicit in the evidence.

Pitfalls and limits

Random identifiers reduce guessing but do not enforce authorization. Cached responses and asynchronous jobs may perform checks at different times. Role names alone do not reveal effective permissions inherited through groups.