BOLA testing with OpenAPI: map operations to owner checks
Use OpenAPI to discover where an operation accepts object identifiers. Add the missing business fact yourself: who owns each fixture and who may act on it. Exercise the same operation as the owner and as an unrelated user.
What to prepare
Start with the specification for the build under review. Pick one private resource and enumerate alternate representations such as an attachment, download or export job.
Verification procedure
Find object selectors beyond path parameters
Record the method, path and operationId when present. Inspect query parameters and request bodies as well: an export may accept an array of document IDs without an ID in the URL.
Attach an access expectation to each operation
List the owner, an unrelated user and any legitimate guest. Prove owner access before changing identities. For asynchronous exports, verify the contents and retrieval permissions of the completed artifact too.
Example test inventory; these are expected decisions, not scan results
GET /documents/{id} → readDocument → owner B: allow; A: deny
GET /documents/{id}/download → downloadFile → owner B: allow; A: deny
POST /exports {documentIds} → createExport → inspect exported objectsDecision and limitations
Keep the observed outcome and spec revision beside each row. Mark an operation untested when you lack a safe fixture or permission to invoke it.
What remains unverified
An OpenAPI security declaration describes the operation’s authentication requirements. It does not prove the server checks ownership. Use known IDs instead of enumerating production data.