Policy and Resource Authorization, IDOR and Tenant Isolation

Authorization layers

Endpoint authorization asks whether the caller may invoke the operation. Resource authorization asks whether the caller may act on this specific object. Data access must also preserve tenant boundaries, and response models must not leak fields the caller should not see.

IDOR example

Changing /orders/123 to /orders/124 must not expose another user's order. Random IDs reduce guessing but do not replace authorization.

A safe flow is:

1. Authenticate the caller.
2. Resolve the tenant from trusted context.
3. Query the resource inside that tenant boundary.
4. Evaluate ownership or a resource policy for the requested operation.
5. Return only the fields allowed for this purpose.

Policies and handlers

A named policy is a set of requirements. Requirements can check permission claims, authentication strength or other context. A resource handler receives the target object and operation, which supports owner, approver and tenant rules without putting all logic in a controller.

Roles can map to permissions, but business actions are often clearer as capabilities such as invoice.approve or user.read. Keep anonymous access explicit and security-critical defaults restrictive.

Tenant isolation

Apply mandatory tenant filters close to data access and test cross-tenant identifiers. Background jobs and administrative tools need the same boundary discipline as HTTP controllers. Never trust a tenant ID solely because the client submitted it.

Negative test matrix

• Missing permission.
• Correct permission, wrong owner.
• Correct role, wrong tenant.
• Resource moved to a state where the action is no longer valid.
• Response accidentally includes another tenant's nested object.

Defense in depth means each layer rejects what it can prove invalid. It does not mean duplicating inconsistent rules across controllers and repositories.