Authorize Each Batch API Operation

A batch endpoint can hide many resource decisions behind one HTTP request. Checking permission on the first item, or on a parent collection, may let later items cross a tenant boundary. Decide whether the batch is atomic or allows partial success, then apply authorization to every item before side effects occur. OWASP API Security Top 10 covers object-level authorization on API operations.

Batch decision table

Write down the transaction rule. If an unauthorized item makes the whole batch fail, verify no earlier item was changed before the failure. If partial success is allowed, return item-level decisions without leaking the foreign item's private fields. A generic “success” response is not enough to explain what happened.

Test the actual effects

Use two synthetic tenants and a batch containing allowed and denied records. Check database rows, queued jobs, emails, and audit events after the request. Repeat with items in a different order so the handler cannot pass only when the denied item appears first. Test a batch large enough to exercise pagination or chunking, but keep it within owned test limits.

OWASP Authorization supports a separate decision for each resource and action. The artifact is the batch table tied to the product's atomicity policy. Include it in the endpoint specification and regression suite. Do not use production customer records to make a mixed batch. If the team has not defined partial failure behavior, hold the endpoint release until it does.

Choose the order of validation and execution. If the batch is atomic, validate all item permissions before changing the first item. If partial success is allowed, keep each result tied to its input index and avoid returning a denied record's private metadata.