Cybersecurity glossary
What is Broken Object Property-Level Authorization (BOPLA)?
Learn what Broken Object Property-Level Authorization (BOPLA) is, how excessive data exposure and mass assignment relate, and how to authorize reads and writes at the field level.
Definition
Broken Object Property-Level Authorization (BOPLA) is an API weakness where the server fails to enforce which object properties a caller may read or write—leading to overshared responses, unauthorized field updates such as role flags, or both.
Why BOPLA matters
Object access can be correct while field access is not. Broken Object Property-Level Authorization (BOPLA) is the gap between “you may touch this order” and “you may see its cost basis / set its status to paid.”
APIs that serialize entire database entities or bind request JSON indiscriminately create BOPLA by default.
Two sides of property failures
Unauthorized reads
Responses include secrets, internal flags, or PII beyond the caller’s need.
Unauthorized writes
Clients modify privileged properties through flexible update endpoints.
Role and tenant flags
Fields like role, plan, or verified become attacker-controlled.
Nested leakage
Expanded relationships expose sensitive child properties unintentionally.
How BOPLA is exploited
Inspect normal API responses
Look for sensitive fields returned to low-privilege callers.
Probe write endpoints
Add privileged properties to PATCH/PUT JSON bodies.
Confirm server acceptance
Observe whether unexpected fields persist on the object.
Escalate privileges
Set admin roles, balances, or feature entitlements as allowed by the bug.
Harvest overshared reads
Script list endpoints that return full entity graphs.
Combine with BOLA
Apply the same property tricks across other users’ objects if IDs are interchangeable.
Controls that enforce property authorization
| Control | Applies to | Effect |
|---|---|---|
| Response DTOs / projections | Read | Return only intended fields |
| Input allowlists | Write | Ignore or reject unknown/privileged properties |
| Field-level policies | Both | Authorize sensitive attributes per role |
| Schema validation | Write | Block undeclared properties at the edge |
BOPLA prevention checklist
- Never serialize raw persistence entities directly to API clients.
- Use dedicated request/response models with explicit properties.
- Authorize sensitive fields (roles, balances, flags) separately from object access.
- Set additionalProperties to false in write schemas where practical.
- Add tests that attempt privileged field injection and expect rejection.
- Review GraphQL field resolvers for authorization on sensitive selections.
- Minimize list endpoint payloads; prefer sparse fieldsets.
- Monitor for unexpected property names in write traffic.
The practical takeaway
BOPLA is authorization at field granularity. Object ownership is not enough when responses overshare or updates over-accept.
Allowlist properties for reads and writes, and treat privileged fields as their own authorization decisions.
Related security terms
Excessive Data Exposure
Read-side oversharing that BOPLA encompasses.
Mass Assignment
Write-side property binding abuse closely tied to BOPLA.
Broken Object-Level Authorization (BOLA)
Object access control; BOPLA focuses on properties inside objects.
API Response Filtering
Techniques to return only authorized fields to each caller.
Schema Validation
Contract enforcement that helps block unexpected writable properties.
Frequently asked questions
What is BOPLA in simple terms?
The API shows or accepts fields the user should not touch—like returning password hashes, or allowing a user to set isAdmin=true in a profile update.
How does BOPLA relate to excessive data exposure?
Excessive data exposure is the read side of property-level failures. BOPLA covers both unauthorized reads and unauthorized writes of properties.
How does BOPLA relate to mass assignment?
Mass assignment is a common write-side BOPLA pattern: binders accept unexpected properties from client JSON.
Where is BOPLA in OWASP API Security?
It appears as Broken Object Property Level Authorization in the OWASP API Security Top 10.
Can GraphQL be affected?
Yes. Clients can request sensitive fields or mutate properties if resolvers lack field-level authorization.
Is filtering in the UI enough?
No. Hidden fields in a mobile app still travel over the API. Enforce property rules on the server.
What is the best mitigation pattern?
Explicit DTOs/allowlists for responses and inputs, plus authorization decisions per sensitive property.
References
Explore authoritative guidance and frameworks related to broken object property-level authorization (bopla).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.