Broken Object Property Level Authorization (BOLPA)
A Guide to Broken Object Property Level Authorization (BOLPA)
Broken object property level authorization, or BOPLA, consolidates two risks from the 2019 list, excessive data exposure and mass assignment, into a single category built around a common root cause: missing or improper authorization checks at the property level of an object.
BOPLA takes two forms. One is data exposure, where an API returns more properties than a given user should see. The other is mass assignment, where an API accepts client-supplied values for properties a user shouldn’t be able to change. Both stem from the same gap: the API validates access to the object as a whole but not to its individual fields.
Because object properties are visible directly in API responses, this vulnerability is easy for attackers to find. Inspecting a response reveals exposed fields. Fuzzing request payloads surfaces hidden, writable ones.
Key Takeaways
- Broken Object Property Level Authorization (BOPLA) is ranked #3 in the OWASP API Security Top 10 2023 and consolidates two previously separate risks: excessive data exposure and mass assignment
- The vulnerability has two distinct faces: APIs that return more object properties than the user should see (data exposure), and APIs that allow users to modify properties they shouldn’t have access to (mass assignment)
- It is easy to exploit: inspecting API responses reveals sensitive properties, while fuzzing can uncover hidden ones that may also be writable
- Real-world impacts range from sensitive data disclosure and privilege escalation to financial manipulation, as demonstrated by scenarios like a guest being overcharged by modifying a price property
- Prevention requires cherry-picking specific properties to return rather than using generic serialization methods, implementing schema-based response validation, and strictly allow listing which properties a client is permitted to modify
Why is it Dangerous
The real-world impact of BOPLA ranges from disclosure to direct financial manipulation. Consequences include:
- Exposure of sensitive properties never intended for the client, such as internal flags or PII
- Privilege escalation through modification of role or permission fields
- Financial manipulation, such as a host injecting a total_stay_price property into a booking request to overcharge a guest
- Downstream trust failures when exposed properties feed other systems
Typical Manifestations
BOPLA commonly appears when:
- An endpoint uses a generic serialization method like to_json() and returns the entire object
- A PATCH or PUT request accepts any field in the payload and writes it to the database without an allowlist
- Internal status fields, such as is_admin or blocked, are both readable and writable by the client
- Response schemas are undocumented, so no one notices when a new sensitive field slips into output
The common denominator: the object is authorized, but its properties are not.
Prevention BOPLA
Property-level control has to be explicit, not inherited from object-level checks.
- Confirm the user should have access to every property an endpoint exposes before returning it
- Specify the properties an endpoint returns instead of serializing the full object with generic methods
- Avoid functions that automatically bind client input into code variables, internal objects, or object properties
- Allow changes only to the specific properties a client should be able to update
- Apply schema-based response validation to catch unintended fields before they ship
- Keep returned data structures to the bare minimum the endpoint’s business requirements call for
A user who is authorized for an object should not automatically be able to see or edit all of its properties.
