Broken object property level authorisation

What it means

Broken object property level authorisation, or BOPLA, is when an API correctly lets you reach a record but does not check which fields of it you may read or change. You may see your own order, but not the internal cost field, and you may edit your address, but not your price tier.

It is number three in the OWASP API Security Top 10 for 2023. It joins two older entries: excessive data exposure on the reading side and mass assignment on the writing side. Both sides have the same cause: the API trusts the shape of the record, not the person asking.

Why it matters

The record check passes, so ordinary testing says access control is working. Yet a customer can read another field they should not, such as a hidden flag or someone's personal details, or can write one, such as their own role or balance.

Writes cause the worst cases. Sending an extra field like isAdmin or credit in a request can change data the form never offered. Reads cause quiet leaks of personal data through fields that the interface hid but the API still sent.

How it shows up

You meet it in APIs that convert whole database records to responses and requests straight into records, often through automatic mapping in a framework. Look at what the response contains compared with what the screen shows, and at which fields a request can set that the form did not include. Related checks sit under object-level authorisation.

The fix is explicit: define which fields each role may read and which it may write, and use separate input and output shapes instead of the database model. Test with extra fields, with fields of other roles, and with a lower-privilege account against the same record.