Broken Object Property Level Authorization (BOPLA)
Abbreviation: BOPLA
Pronunciation: BROH-kun OB-jekt PROP-er-tee LEV-ul aw-thur-ih-ZAY-shun (B-O-P-L-A)
Also known as: BOPLA
Definition
Broken Object Property Level Authorization (BOPLA) is an API flaw that exposes or permits modification of object fields that the requesting principal is not authorized to read or change. It can arise from excessive data exposure or mass assignment even when access to the overall object is legitimate. Controls include explicit response schemas, allowlisted writable fields, field-level authorization, separate input and output models, safe serialization, negative testing, and review of nested properties and version changes.
Overview
Broken Object Property Level Authorization (BOPLA) is an API flaw that exposes or permits modification of object fields that the requesting principal is not authorized to read or change. The control exists to prevent APIs and applications from allowing unauthorized data access, privileged functions, unsafe state changes, or execution through defective design or implementation. It can arise from excessive data exposure or mass assignment even when access to the overall object is legitimate. It should be interpreted alongside Broken Function Level Authorization (BFLA) because the concepts can affect the same decision without representing the same control, event, or risk.
The workflow starts with explicit trust boundaries, identities, objects, fields, functions, states, and allowed transitions. Server-side controls validate every request, use restrictive schemas, calculate authoritative values, and reject operations that violate authorization, sequence, rate, content, or business rules. In this context, controls include explicit response schemas, allowlisted writable fields, field-level authorization, separate input and output models, safe serialization, negative testing, and review of nested properties and version changes.
It should connect the term to API Schema where that relationship changes access, transaction treatment, investigation, communication, or recovery.
Testing should include positive and negative authorization cases, multiple roles and tenants, malformed and replayed requests, concurrency, version changes, nested data, recovery paths, and production-like configurations. Logs should connect principal, request, resource, decision, error, and resulting state without recording secrets.
Useful measures include endpoint coverage, failed authorization tests, vulnerable versions, time to remediate, abuse attempts, error and rejection rates, recurring defect classes, and differences between specification and deployed behavior.
The relationship with Data Loss Prevention (DLP) should be documented where it affects residual risk or control ownership.
Key Takeaway
Controls include explicit response schemas, allowlisted writable fields, field-level authorization, separate input and output models, safe serialization, negative testing, and review of nested properties and version changes.
Sources
- API3:2023 Broken Object Property Level Authorization — OWASP (2026-08-03)
- OWASP API Security Top 10 – 2023 — OWASP (2026-08-03)
- Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5 — NIST (2026-08-03)