OWASP API3:2023 Broken Object Property Level Authorization, or BOPLA, occurs when an API exposes or accepts object properties that a caller should not be allowed to read or modify. The object itself may be legitimate for the caller. The failure exists inside the object: an internal field appears in a response, a protected property can be changed, or a broad update operation accepts data that should remain server controlled.
What Is OWASP API3:2023 Broken Object Property Level Authorization?
BOPLA is a property-level authorization failure. It affects both directions of an API contract:
- Read-side BOPLA: the API returns a property that the caller should not see or does not need.
- Write-side BOPLA: the API allows the caller to add, change, or delete a protected property.
Examples include exposing administrative notes in a customer response, returning another tenant’s internal account flags, accepting a role or owner field from a normal user, or allowing a broad partial update to change approval state.
A complete authorization decision should answer:
- May this identity access the object?
- May this identity read this property through this operation?
- May this identity write this property through this operation?
- Is the requested state transition allowed now?
- Does the operation need to return or accept the property at all?
Why OWASP Combined Excessive Data Exposure and Mass Assignment
The OWASP API Security Top 10 – 2023 combined the former API3:2019 Excessive Data Exposure and API6:2019 Mass Assignment categories. Both commonly result from missing or incorrect authorization at the object-property level.
| Earlier category | Direction | Typical failure | API3:2023 interpretation |
|---|---|---|---|
| Excessive Data Exposure | API to caller | A response contains properties the caller should not receive | Broken read authorization for object properties |
| Mass Assignment | Caller to API | A request can set properties the caller should not control | Broken write authorization for object properties |
This combined model is useful because read and write failures often share the same causes: broad internal models, reused schemas, incomplete role rules, automatic serialization, automatic binding, and weak operation-specific authorization.
BOPLA vs. BOLA, Function Authorization, and Parameter Tampering
| Risk | Primary question | Example |
|---|---|---|
| BOLA or IDOR | May the caller access this object? | A user changes an invoice ID and receives another customer’s invoice |
| BOPLA | Which properties of the object may the caller read or write? | A valid profile response contains internal risk flags |
| Broken function-level authorization | May the caller invoke this operation? | A normal user calls an administrative suspension action |
| Parameter tampering | Does changing a client value bypass a server rule? | A caller changes owner, role, price, or status and the server accepts it |
| Business-logic abuse | Does a valid sequence create a harmful business outcome? | A promotion or workflow is repeated beyond its intended use |
One request can reveal several risks. A changed object ID may produce BOLA, while the returned object also exposes restricted fields through BOPLA. A broad update endpoint may combine property authorization and function authorization failures.
For object access, review BOLA and IDOR API security. For client-controlled values, review API parameter tampering.
Common BOPLA Patterns
| Pattern | What looks normal | Property-level failure |
|---|---|---|
| Full backend object in a response | The endpoint returns a valid customer or account object | Internal notes, permissions, fraud flags, tenant fields, or secrets are included |
| Client-side filtering | The user interface hides restricted values | The API still sends the properties to the browser or mobile client |
| Broad automatic request binding | The request body matches a domain or persistence model | Unexpected properties can alter owner, role, state, price, or internal flags |
| Shared schema across roles | One model is convenient for users, partners, support, and administrators | Every audience receives or can submit the same property set |
| Generic partial update | A PATCH operation accepts arbitrary property paths | The caller can target properties outside the intended operation |
| GraphQL field or mutation overreach | The schema exposes flexible selections or input objects | Resolvers do not enforce field-level read or write permissions |
| Bulk update | The endpoint modifies many objects efficiently | Per-object and per-property authorization is applied incompletely |
| Schema drift | A release adds a useful field | The new property reaches clients before security and privacy rules are updated |
Why BOPLA Happens
Internal models become public contracts
Database or domain entities are serialized and bound directly instead of being mapped through narrow API models.
Authorization stops at the object
The API verifies ownership but assumes all properties inside an allowed object are equally accessible.
Roles are too coarse
Property rules vary by operation, tenant, object state, relationship, and business purpose—not only by a global role.
Clients are trusted to hide data
Frontend filtering is mistaken for response authorization.
Automatic binding is too broad
Framework convenience maps unapproved request properties into internal objects.
Partial updates lack path controls
Generic patch documents or field maps accept sensitive properties without explicit allowlists.
Contracts are reused
Public, partner, administrative, and internal operations use one large schema.
Production behavior is not observed
New fields, real roles, legacy routes, and alternate clients escape pre-release testing.
Build an Explicit Property Authorization Model
Property authorization should be defined by operation and context. A field can be readable but not writable, writable only during creation, visible only to support staff, or available only when the object is in a particular state.
| Property | Customer read | Customer write | Support read | Administrator write | Server owned |
|---|---|---|---|---|---|
| displayName | Yes | Yes | Yes | Yes | No |
| Yes | Through verified change flow | Masked | Restricted | Partly | |
| tenantId | Usually no | No | Yes | Restricted | Yes |
| riskFlag | No | No | Restricted | Restricted | Yes |
| role | Limited | No | Limited | Through dedicated action | Controlled |
| accountStatus | Yes | No | Yes | Through approved transition | Controlled |
The matrix should also include tenant relationship, object ownership, business state, client type, data classification, and the operation where access is allowed. Store the rule close enough to the application to use real domain context.
How to Prevent BOPLA
Use operation-specific request and response models
Create separate models for registration, profile update, administrative review, partner access, search results, and internal processing. Avoid exposing one broad object everywhere.
Map properties deliberately
Build responses from approved values and map request fields into explicit commands or DTOs. Do not serialize persistence entities or bind arbitrary request properties directly into domain objects.
Authorize read and write directions separately
A caller may be allowed to see a field without changing it, or update a field without receiving its internal representation. Treat read and write decisions independently.
Keep protected values server controlled
Role, tenant, owner, balance, risk decision, approval state, internal flags, calculated price, and audit fields should normally be derived or changed through dedicated trusted operations.
Minimize responses
Return only the fields and records required for the operation and recipient. Removing unnecessary properties reduces privacy, security, compatibility, and monitoring risk.
Reject unknown or protected properties
Strict rejection is often safer because it exposes incorrect clients and attempted over-posting. If compatibility requires ignoring unknown fields, record the behavior and ensure protected fields cannot be silently accepted.
Apply authorization after loading trusted state
Property rules may depend on object ownership, tenant, current state, account relationship, or prior approval. Retrieve the trusted object and evaluate the rule before returning or changing the property.
Secure PATCH, JSON Patch, GraphQL Mutations, and Bulk Operations
Flexible update mechanisms are useful, but they expand the property authorization surface.
| Update style | Primary BOPLA concern | Safer requirement |
|---|---|---|
| JSON Merge Patch | Any supplied property may be applied to the object | Allowlist properties by operation and authorize null or deletion semantics |
| JSON Patch | Patch paths and operations can target protected or nested values | Restrict operations and paths, authorize each path, and validate final state |
| GraphQL mutation | Broad input types allow sensitive properties or nested writes | Use narrow input types and enforce resolver-level property and object rules |
| Field map or key-value update | Dynamic names bypass static request models | Map supported keys to explicit commands and reject everything else |
| Bulk update | One decision is reused across many objects or tenants | Authorize each object and property, limit scope, and record partial failures |
| Administrative import | Trusted file or integration can overwrite server-owned properties | Validate source identity, schema, property permissions, approvals, and audit trail |
After applying a partial update, validate the complete resulting object and the requested state transition. A valid property value can still be unauthorized in the current context.
Use OpenAPI and JSON Schema Carefully
OpenAPI can describe operation-specific request bodies, response bodies, properties, required fields, content types, and security schemes. This makes the contract useful for design review, client generation, testing, gateway validation, and runtime drift detection.
- Use separate request and response schemas.
- Create narrow schemas for different operations and audiences.
- Restrict undeclared properties where compatibility permits.
- Document nested objects, arrays, bulk operations, files, errors, and alternate media types.
- Review new response and input properties as security and privacy changes.
- Compare the approved contract with gateway configuration and observed runtime fields.
The OpenAPI `readOnly` and `writeOnly` annotations can help tools understand direction, but they do not enforce authorization. Server-side application logic or a trusted policy point must still decide whether the current caller may read or write the property.
Use API schema drift detection for the production contract-monitoring workflow.
Defensive BOPLA Testing Method
Testing should verify expected-denied behavior across roles, objects, operations, and states. Perform it only in authorized test environments or approved assessments.
| Step | Assessment activity | Evidence |
|---|---|---|
| 1. Inventory object operations | List create, read, search, export, update, patch, delete, bulk, partner, and administrative operations | Operation and owner matrix |
| 2. Enumerate properties | Compare public schemas, responses, request models, domain objects, and persistence entities | Readable, writable, internal, and server-owned property list |
| 3. Define authorization rules | Document permissions by role, tenant, relationship, operation, object state, and client | Property authorization matrix |
| 4. Test read boundaries | Compare response fields across approved identities and object contexts | Expected and actual response properties |
| 5. Test write boundaries | Submit only approved negative cases for restricted, unknown, nested, and server-owned properties | Response, persisted state, audit, and downstream results |
| 6. Test flexible operations | Review PATCH formats, GraphQL mutations, bulk actions, imports, and alternate content types | Path, operation, object, and final-state authorization results |
| 7. Test related routes | Review old versions, partner APIs, mobile routes, direct services, and asynchronous consumers | Coverage and limitation record |
| 8. Create regression coverage | Turn confirmed failures into repeatable role- and property-aware tests | Automated acceptance criteria |
The OWASP Web Security Testing Guide includes a focused excessive-data-exposure test and maps it to API3:2023. The OWASP Mass Assignment Cheat Sheet recommends allowlisting properties and using request-specific models.
For the combined lifecycle, review API security testing vs. runtime monitoring.
Runtime Signals for BOPLA
Testing proves selected cases. Runtime monitoring helps identify undocumented APIs, real client roles, schema drift, unexpected data combinations, and behavior that appears only in production.
| Runtime signal | Why it matters | Validation context |
|---|---|---|
| First-seen response property | A release or unmanaged route begins returning a new field | Specification, deployment, audience, data class, and owner |
| Sensitive field on an unexpected route | The operation may expose data outside its business purpose | Role, tenant, object, client, and expected response contract |
| Role-to-property mismatch | A low-privilege caller receives or submits an administrative property | Identity, operation, policy, object state, and outcome |
| Unknown writable property | The API may be binding fields beyond the documented request model | Request schema, framework behavior, persistence, and audit record |
| Protected property change | Role, owner, tenant, state, price, or internal flags change unexpectedly | Previous value, caller, command, workflow, and downstream effect |
| Schema drift across versions | Legacy or alternate routes may expose broader object models | Version, gateway route, client, owner, and specification |
| Successful sensitive response | The property exposure produced a real outcome | Status, returned fields, object count, data class, and affected population |
| Telemetry gap | The team cannot determine which properties were returned or changed | Collection point, encryption boundary, sampling, and affected APIs |
Responses and Persisted Outcomes Determine Severity
| Observed behavior | Outcome evidence | Interpretation |
|---|---|---|
| A request includes a protected role property | The property is rejected and no state changes | Attempted or accidental over-posting with an effective control |
| A request includes a protected role property | The role changes in the database or audit trail | Confirmed write-side BOPLA with possible privilege escalation |
| A profile response contains an internal field | The value is non-sensitive and approved for the client | Legitimate contract change that still requires documentation |
| A profile response contains an internal field | The field reveals risk, tenant, credential, or confidential data | Material read-side BOPLA requiring scoping |
| A patch targets a protected nested path | The service denies the operation before persistence | Attempted property manipulation with an effective path rule |
| A bulk update includes mixed authorized objects | Unauthorized objects or properties are still modified | Scope and per-object authorization failure |
Reduce False Positives
Use operation context
A property may be valid on an administrative route and prohibited on a customer route.
Separate read and write rules
A property can be visible but server controlled, or writable without exposing its internal representation.
Correlate releases
New fields may be legitimate, but they still require owner, schema, authorization, and data-class review.
Confirm the outcome
Prioritize properties that were returned successfully or persisted, not only attempted inputs.
Segment by audience
Customers, partners, support staff, administrators, and services can have different approved property sets.
Expire exceptions
Temporary exposure, compatibility rules, and suppressions need scope, owner, reason, and review date.
SIEM-Ready BOPLA Event Model
Event category, confidence, and severity Application, environment, endpoint, method, version, and API owner User, workload, client, token, tenant, and source context Object type, object identifier category, and ownership context Property names or classifications and read/write direction Expected property authorization rule or response schema Request operation, patch path, mutation, or bulk context Response status, returned fields, object count, and size Persisted change, audit result, and downstream business outcome First-seen, schema-drift, release, and related-event context Affected users, tenants, objects, and sensitive-data categories Evidence limitations and telemetry-health status Recommended validation, containment, or remediation action Case and correlation identifiers
Use centralized SIEM log-forwarding formats so the event remains useful outside the API security platform.
BOPLA Remediation and Verification Workflow
| Phase | Required work | Closure evidence |
|---|---|---|
| 1. Validate | Confirm the identity, object, property, operation, response or state change, and authorization rule | Reproducible authorized test or production evidence |
| 2. Scope | Review related roles, objects, schemas, models, versions, clients, and operations | Affected-surface assessment |
| 3. Correct the model | Create narrow request and response contracts and explicit readable and writable rules | Reviewed design and implementation |
| 4. Correct the operation | Fix mapping, binding, resolver, patch, bulk, and state-transition controls | Code, policy, or configuration change |
| 5. Test related paths | Run negative and regression tests across roles, versions, formats, and alternate routes | Passing acceptance tests |
| 6. Validate deployment | Confirm the intended version and configuration are active everywhere | Deployment evidence |
| 7. Observe production | Verify that restricted fields are no longer returned or writable and telemetry remains healthy | Runtime evidence during the agreed validation period |
| 8. Close or accept | Close only when acceptance criteria are met or residual risk is formally approved | Verified closure or time-bound exception |
For deeper write-side remediation, use mass assignment API vulnerability. For read-side scoping, use API sensitive data exposure and API forensics.
BOPLA Program Metrics
| Metric | Definition | Interpretation caution |
|---|---|---|
| Property authorization coverage | Critical operations with approved readable and writable rules / all critical object operations | A documented matrix does not prove implementation |
| Operation-specific schema coverage | In-scope operations using narrow request and response schemas / all in-scope operations | Shared schemas may hide role differences |
| Negative-test coverage | Required role, object, property, state, and update-format cases tested / all required cases | Count contexts, not only endpoints |
| Runtime response coverage | Critical read operations with usable field, identity, object, and telemetry evidence / all critical read operations | State unobservable routes separately |
| Protected-property write rate | Requests attempting server-owned or unauthorized properties / monitored write requests | Separate client defects from malicious behavior |
| Confirmed BOPLA rate | Validated unauthorized property reads or writes / reviewed BOPLA events | Separate attempted access from successful outcomes |
| Mean time to validate | Time from event or finding creation to reliable disposition and owner assignment | Separate automation from human review |
| High-risk issue age | Open material BOPLA issues grouped by owner, age, and treatment | Show accepted risk separately |
| Verified remediation rate | Closed material issues with successful test and production evidence / all closed material issues | Ticket closure alone is not verification |
| Recurring root-cause rate | Previously addressed broad-model, binding, schema, or authorization failures that return | Normalize by root cause rather than alert title |
90-Day BOPLA Improvement Roadmap
| Period | Primary objective | Key outputs |
|---|---|---|
| Days 1–30 | Inventory and define | Critical object operations, property inventory, data classes, server-owned fields, authorization matrix, schema gaps, owners, and pilot scope |
| Days 31–60 | Test and observe | Read and write negative tests, patch and bulk coverage, response-field monitoring, SIEM events, telemetry-health checks, and prioritized findings |
| Days 61–90 | Remediate and operationalize | Narrow DTOs, mapping standards, verified fixes, regression tests, metrics, runbooks, exception review, and expansion plan |
OWASP API3:2023 BOPLA Prevention Checklist
| Checklist item | Validation question | Status |
|---|---|---|
| Object operations inventoried | Are read, search, export, create, update, patch, bulk, partner, and administrative operations known? | Required |
| Property inventory | Are public, sensitive, internal, server-owned, readable, and writable fields classified? | Required |
| Read authorization | Are response properties authorized by operation, identity, tenant, object, state, and purpose? | Required |
| Write authorization | Are request properties authorized independently from object and route access? | Required |
| Operation-specific DTOs | Are narrow request and response models separated from domain and database models? | Required |
| Server-owned properties | Are role, owner, tenant, status, risk, balance, audit, and calculated values protected? | Required |
| Unknown-property handling | Are undeclared and protected fields rejected or guaranteed to be ignored safely? | Required |
| Partial-update safety | Are patch operations, paths, nested values, final state, and deletion semantics authorized? | Required |
| GraphQL and bulk safety | Are input fields, resolvers, per-object decisions, partial failures, and scope controlled? | Required |
| Response minimization | Does each operation return only the fields and records required by the recipient? | Required |
| Negative testing | Are expected-denied property reads and writes tested across roles, tenants, states, and versions? | Required |
| Runtime visibility | Can new, sensitive, role-mismatched, and protected properties be detected in requests and responses? | Recommended |
| SIEM workflow | Do events contain identity, object, property, direction, expected rule, outcome, owner, and action? | Recommended |
| Remediation verification | Are fixes retested and observed after deployment before closure? | Required |
| Frontend filtering | Is the API sending restricted fields and relying on the client to hide them? | Avoid |
For the wider program, use API security architecture design and API security implementation playbook.
Common BOPLA Prevention Mistakes
Using the unofficial category name
The official OWASP title is Broken Object Property Level Authorization. Keep the exact terminology in the article and metadata.
Assuming object access covers every property
Object ownership does not automatically allow every read or write inside the object.
Returning full backend models
Internal fields reach clients and become difficult to remove without breaking compatibility.
Trusting frontend filtering
Hidden fields remain available in the API response and network traffic.
Using one update model everywhere
Normal users, partners, support teams, and administrators usually need different writable fields.
Ignoring PATCH and bulk operations
Flexible updates can bypass property rules that exist on ordinary create and update endpoints.
Treating schema annotations as enforcement
Contracts help describe intent, but server-side authorization must enforce the decision.
Closing after a code change
Related roles, routes, versions, formats, and deployed behavior must be verified before closure.
Authoritative Guidance
- OWASP API3:2023 Broken Object Property Level Authorization defines the official risk and its read- and write-side conditions.
- OWASP API Security Top 10 – 2023 Release Notes explain why Excessive Data Exposure and Mass Assignment were combined.
- OWASP Mass Assignment Cheat Sheet recommends request-specific models and property allowlisting.
- OWASP Testing for Excessive Data Exposure provides defensive API response and mass-assignment testing guidance.
- OpenAPI Specification 3.2.0 defines the current standard interface-description model for HTTP APIs.
- NIST SP 800-228 Update 1 provides API risks and recommended controls across pre-runtime and runtime lifecycle stages.
- OWASP REST Security Cheat Sheet provides practical guidance for access control, validation, content types, errors, and logging.
Conclusion
OWASP API3:2023 BOPLA is not only an excessive-response problem and not only a mass-assignment problem. It is the failure to enforce which properties a caller may read or write for a particular object, operation, tenant, relationship, and state.
The strongest defense combines operation-specific contracts, explicit readable and writable rules, server-side mapping, protected server-owned values, safe partial updates, response minimization, negative testing, runtime request and response evidence, SIEM workflows, and verified remediation. That approach addresses the shared root cause identified by OWASP without treating every new field or rejected property as a confirmed vulnerability.
Frequently Asked Questions
What is OWASP API3:2023 Broken Object Property Level Authorization?
OWASP API3:2023 Broken Object Property Level Authorization, commonly called BOPLA, occurs when an API allows a caller to read, add, change, or delete object properties that the caller should not be allowed to access.
Why did OWASP combine excessive data exposure and mass assignment?
OWASP combined the earlier Excessive Data Exposure and Mass Assignment categories because both commonly result from the same root problem: the API does not enforce authorization for individual object properties.
How is BOPLA different from BOLA or IDOR?
BOLA or IDOR asks whether the caller may access the object at all. BOPLA asks which properties of an allowed object the caller may read or modify. An API can enforce object ownership correctly and still expose or accept restricted fields.
How is BOPLA different from broken function-level authorization?
Broken function-level authorization allows a caller to invoke a restricted operation or administrative function. BOPLA concerns properties inside the object being read or changed. A single endpoint can contain both problems.
What are common read-side BOPLA examples?
Common examples include returning internal notes, administrative flags, permissions, tenant identifiers, financial details, risk scores, secrets, or personal data that the caller does not need or is not authorized to see.
What are common write-side BOPLA examples?
Common examples include allowing a caller to set role, owner, tenant, approval state, account status, discount, balance, internal flags, or other protected properties through broad request binding or an overly permissive update operation.
How can teams prevent BOPLA?
Use operation-specific request and response models, explicit readable and writable property rules, server-side object and property authorization, deliberate mapping, narrow schemas, safe partial-update handling, response minimization, and regression tests.
Do OpenAPI readOnly and writeOnly properties prevent BOPLA?
No. They are useful contract annotations for tools and documentation, but they do not independently enforce authorization. The application or trusted policy point must still decide which properties each caller may read or write.
How should PATCH and bulk update endpoints be secured?
Authorize every targeted property and state transition, restrict supported operations, reject unknown or protected paths, validate the resulting object, limit bulk scope, and preserve audit evidence. Do not assume partial updates are safe because they contain fewer fields.
How can runtime monitoring detect BOPLA?
Runtime monitoring can identify first-seen response fields, sensitive fields on unexpected routes, role-to-property mismatches, protected write attempts, schema drift, broad object binding, successful sensitive responses, and unusual property-change patterns.
What should a SIEM-ready BOPLA event contain?
Include the application, endpoint, identity, tenant, object, property names or classifications, read or write direction, expected authorization rule, response or persisted outcome, confidence, affected scope, owner, and recommended validation or remediation action.
How should BOPLA remediation be verified?
Repeat the authorized negative test, inspect the deployed response or state change, test related roles, routes, versions, bulk operations, and alternate update formats, confirm telemetry health, and close the issue only when acceptance criteria prove that restricted properties are no longer exposed or writable.
See which properties your APIs expose and accept at runtime
Ammune helps teams discover active APIs, inspect approved request and response context, identify sensitive properties and schema drift, analyze authorization behavior, forward SIEM-ready evidence, and support remediation verification.