API security: broken object-level authorisation explained

A login answers only one question

Authentication establishes who is making a request. Authorisation determines what they can do. Broken object-level authorisation occurs when an API accepts a record identifier without checking whether the caller may access that particular record.

A business example

A customer downloads their own invoice through an API. If substituting another invoice identifier returns someone else’s invoice, the API has crossed an ownership boundary. Random identifiers reduce guessing but do not replace an ownership check.

Define an authorised test

Use two accounts and synthetic records on systems explicitly included in your written testing scope. Check the expected permissions before making requests. Do not try these checks against services you do not own or have permission to assess.

• Check reads, edits, deletions and attachments separately
• Include batch endpoints and exports
• Test ordinary users as well as administrators
• Verify that rejected requests do not disclose the protected record

Fix the underlying rule

Check ownership or permitted membership on the server for every object operation. Use a shared data-access pattern so the same rule applies across endpoints. Also consider field-level permissions: someone allowed to update a profile should not be able to set an approval or administrator field.

Prevent repeat failures

Keep regression tests that request account A’s record as account B and expect rejection. Repeat them for newly added endpoints. Log enough information to investigate attempted misuse, but do not put tokens or confidential response bodies into logs.