OWASP API3:2023 Broken Object Property Authorization, more commonly named Broken Object Property Level Authorization, is about field-level access inside API objects. A caller may be allowed to access a customer, account, order, or profile object, but that does not mean they should be allowed to read or modify every property inside that object.
What Is OWASP API3:2023 Broken Object Property Authorization?
Broken Object Property Level Authorization happens when an API fails to enforce authorization at the property level. The issue may appear when an API response includes sensitive fields the caller should not see, or when a request lets the caller set properties they should not be able to change.
This category brings together two common API failure patterns: excessive data exposure and mass assignment. Excessive data exposure occurs when an API returns too many fields. Mass assignment occurs when an API accepts too many fields. Both problems come from weak control over object properties.
Why Broken Object Property Authorization Is Dangerous
BOPLA is dangerous because the API may be returning or accepting valid-looking data. The endpoint works, the caller is authenticated, and the object may be allowed. The weakness is that sensitive or restricted properties are not filtered, protected, or validated correctly.
It exposes sensitive fields
APIs may return roles, permissions, internal notes, PII, PCI, tokens, secrets, account flags, financial fields, or administrative metadata.
It enables unsafe modification
APIs may accept fields such as role, plan, balance, status, approval flag, tenant ID, permission set, or internal configuration from the client.
It hides behind normal responses
The response may look successful and expected unless teams inspect which fields were returned and whether each one was authorized.
It spreads through object reuse
When backend objects are reused directly in API responses or request binding, the same property-level mistake can appear across many endpoints.
BOPLA should be evaluated alongside API sensitive data exposure, business logic abuse API security, and OWASP API1:2023 Broken Object Level Authorization.
Common BOPLA Patterns to Review
Defensive BOPLA review should focus on the properties that enter and leave the API. Teams should know which fields are safe to return, which fields are safe to accept, and which fields require role, scope, tenant, or workflow-specific authorization.
| Pattern | What to review | Risk if weak | Priority |
|---|---|---|---|
| Excessive response properties | Full backend objects returned to clients without field filtering | Sensitive data exposure | Required |
| Mass assignment | Client-supplied payload fields bound directly to backend objects | Unauthorized field modification | Required |
| Role and permission fields | Role, privilege, admin, approval, status, scope, entitlement, and plan fields | Privilege or workflow manipulation | Required |
| Internal metadata | Internal IDs, notes, flags, risk indicators, debug fields, system references | Information leakage and abuse support | Recommended |
| Bulk and export APIs | Large objects, reports, file exports, async jobs, and admin exports | Large-scale exposure | Recommended |
| Frontend-only filtering | Client hides fields after API returns them | API still exposes the data | Avoid |
Safe BOPLA Review Questions
Defensive BOPLA review questions: - Which properties does this API return? - Which returned properties are sensitive, internal, privileged, or unnecessary? - Which properties does this API accept from the client? - Which accepted properties are writable by this caller, role, tenant, or workflow? - Are readable and writable fields controlled by explicit allowlists? - Are internal database models separated from external API models? - Are response schemas minimized for each client and use case? - Can runtime monitoring detect sensitive fields and unexpected property changes?
Review patterns should connect with API threat modeling guide, API security CI/CD pipeline, and can API security be solved in development.
How to Prevent Broken Object Property Authorization
BOPLA prevention requires explicit control over properties. APIs should not expose or accept fields simply because those fields exist in a backend object. Readable and writable properties should be designed, reviewed, authorized, tested, and monitored.
| Prevention control | How it helps | Implementation note |
|---|---|---|
| Readable field allowlists | Limits responses to properties the caller is allowed to see | Define per endpoint, role, client, and workflow |
| Writable field allowlists | Prevents unsafe mass assignment of restricted fields | Reject or ignore unexpected fields safely |
| Separate API models | Prevents internal database objects from leaking into external responses | Use response DTOs or external schemas |
| Property-level authorization | Controls sensitive fields by role, scope, tenant, workflow, or entitlement | Apply where fields have different access rules |
| Negative property tests | Validates callers cannot read or write restricted fields | Use safe authorized test environments |
| Blind object binding | Copies client payload directly into backend objects | Avoid |
Example Defensive Property Authorization Requirement
BOPLA prevention requirement: For every API that returns or accepts an object: - Define readable properties for each endpoint, caller, role, and workflow - Define writable properties separately from readable properties - Deny or ignore unexpected writable fields safely - Keep internal model fields out of external API responses - Review sensitive properties such as role, status, token, secret, balance, permissions, tenant, and internal notes - Test expected-allowed and expected-denied property access cases - Monitor runtime responses and request payloads for sensitive fields and schema drift
Prevention work should align with API security implementation playbook, API security architecture design, and how to evaluate API security.
Runtime Detection, SIEM, and BOPLA Operations
Runtime monitoring helps validate that property-level controls are working in production. It can detect when APIs return sensitive fields, when schemas drift from expectations, when writable fields appear in requests, and when callers interact with properties in unusual ways.
Sensitive response properties
Detect PII, PCI, identity fields, tokens, secrets, permissions, internal notes, debug values, financial data, and excessive response fields.
Writable property anomalies
Identify unexpected request fields, restricted property update attempts, privilege-related changes, and payload drift from expected schemas.
API discovery and schema drift
Find new endpoints, changed schemas, changed response shapes, expanded objects, and APIs returning properties not covered by review.
SIEM-ready evidence
Send structured findings with endpoint, method, caller, object type, property category, response context, risk score, owner, and action.
| Runtime signal | What it may indicate | Operational response |
|---|---|---|
| Sensitive property in response | Excessive data exposure or missing field filtering | Review response schema and authorization |
| Unexpected writable property | Possible mass assignment risk | Review writable allowlist and binding logic |
| Role or status field in request | Potential privilege or workflow manipulation attempt | Escalate to AppSec and API owner |
| Schema drift after release | New properties may bypass review and testing | Update API inventory and release gates |
| Bulk response with sensitive fields | Large-scale exposure risk | Review export scope and response minimization |
| Alert without property context | SOC cannot validate BOPLA risk quickly | Improve event fields |
Example BOPLA SIEM Event
{
"alert_category": "api_broken_object_property_authorization_risk",
"owasp_category": "API3:2023 Broken Object Property Level Authorization",
"endpoint": "GET /api/customers/{customer_id}/profile",
"method": "GET",
"caller": "web_portal_user",
"object_type": "customer_profile",
"property_category": "sensitive_identity_field",
"response_status": 200,
"runtime_signal": "excessive_response_property",
"sensitive_data": ["pii", "internal_reference"],
"risk_score": 89,
"owner": "customer-profile-api-team",
"recommended_action": "review response minimization and property-level authorization"
}Runtime operations should connect with API behavior analytics, API risk scoring, and centralized SIEM log forwarding formats.
BOPLA Remediation Workflow
A BOPLA finding should trigger a review of both response properties and writable request properties. The team should also check related endpoints because the same object model or binding pattern may be reused elsewhere.
Validate the property exposure
Confirm affected endpoint, object type, property category, caller context, response impact, and whether the field should be readable or writable.
Review related models
Check whether the same backend object, DTO, serializer, schema, mapper, or binding pattern is reused across related APIs.
Fix readable and writable controls
Add or tighten allowlists, separate internal and external models, enforce field-level authorization, and reject restricted request fields.
Add regression coverage
Add negative tests, schema checks, CI/CD gates, runtime detections, SIEM fields, and owner mapping for future property changes.
Example Remediation Tracker Entry
BOPLA remediation tracker:
- Finding: customer profile API returns internal identity reference
- Affected API: GET /api/customers/{customer_id}/profile
- Object type: customer_profile
- Property category: internal_reference
- Owner: customer-profile-api-team
- Fix: remove property from public response model and add readable allowlist
- Related review: profile update, admin profile, export, partner profile APIs
- Tests: expected public fields and expected-denied sensitive fields
- Runtime validation: monitor profile response schema after release
- Status: remediation and validation requiredRemediation should align with API security operational handover, API security managed detection service, and API security executive reporting.
OWASP API3:2023 BOPLA Prevention Checklist
Use this checklist to evaluate whether APIs are protected against Broken Object Property Level Authorization.
| Checklist item | Question to answer | Status |
|---|---|---|
| Property inventory | Are readable and writable properties documented for sensitive API objects? | Required |
| Readable allowlists | Does each endpoint return only properties the caller, role, client, and workflow should see? | Required |
| Writable allowlists | Does each endpoint accept only properties the caller is allowed to create or modify? | Required |
| Internal model separation | Are internal database models separated from external API response and request models? | Required |
| Mass assignment protection | Are unexpected, restricted, privileged, or internal properties rejected or safely ignored? | Required |
| Response minimization | Are sensitive, internal, excessive, or unnecessary fields removed from responses? | Recommended |
| Runtime monitoring | Can teams detect sensitive response properties, schema drift, unexpected fields, and mass assignment indicators? | Recommended |
| SIEM workflow | Do BOPLA events include endpoint, caller, object type, property category, risk score, owner, and recommended action? | Recommended |
| Frontend-only filtering | Is the API returning sensitive properties and relying on the client to hide them? | Avoid |
Common API Security Risks Connected to BOPLA
OWASP API3:2023 Broken Object Property Authorization connects to the broader API security operating model. Runtime API visibility, request and response inspection, sensitive data exposure, API behavior analytics, API abuse detection, BOLA and IDOR signals, broken object property authorization, business logic abuse, API data leakage, token and secrets leakage, replay attacks, enumeration attacks, SIEM-ready events, incident response, API forensics, API threat hunting, alert fatigue reduction, vendor evaluation, safe enforcement, customer onboarding, proof of value, managed service delivery, executive reporting, renewal planning, and expansion opportunities all matter when building a complete defense.
The practical approach is to prevent BOPLA in development, validate readable and writable fields in testing, monitor response and request properties in production, and route findings into SIEM, AppSec, API owner, and executive reporting workflows.
Conclusion
OWASP API3:2023 Broken Object Property Authorization is a serious API risk because it affects the fields inside objects. A caller may be allowed to access a resource, but that does not mean every property should be visible or writable.
Strong BOPLA defense combines property-level authorization, response minimization, writable field allowlists, mass assignment protection, separate API models, negative testing, runtime response inspection, SIEM-ready evidence, runbooks, owner mapping, and remediation tracking.
FAQ
What is OWASP API3:2023 Broken Object Property Authorization?
OWASP API3:2023 Broken Object Property Authorization, commonly referred to as Broken Object Property Level Authorization or BOPLA, is an API risk where callers can read or modify object properties they should not be allowed to access.
Why is BOPLA important in API security?
BOPLA is important because APIs often return or accept full objects. If the API does not enforce authorization at the property level, users may see sensitive fields or modify restricted fields even when object-level access appears valid.
How is BOPLA different from BOLA?
BOLA focuses on whether a caller can access the object at all. BOPLA focuses on which properties of an allowed object the caller can read or modify. A caller may be allowed to access an object but not every field inside it.
How is BOPLA related to excessive data exposure?
BOPLA includes excessive data exposure when APIs return object properties that the caller or client does not need or is not authorized to see, such as internal notes, permissions, identity data, tokens, financial fields, or sensitive profile attributes.
How is BOPLA related to mass assignment?
BOPLA includes mass assignment when APIs accept client-supplied properties and bind them directly to backend objects without checking whether the caller is allowed to set or change those properties.
What causes Broken Object Property Level Authorization?
Common causes include returning full backend objects, relying on the client to hide fields, weak response filtering, unsafe object binding, missing allowlists for writable properties, inconsistent field-level authorization, and lack of runtime response inspection.
How can teams prevent BOPLA?
Teams can prevent BOPLA by enforcing property-level authorization, minimizing responses, using explicit allowlists for readable and writable fields, avoiding blind object binding, separating public and internal models, and testing expected-denied property access.
What APIs should be prioritized for BOPLA review?
Prioritize APIs that return or accept customer profiles, account data, payment data, identity fields, permissions, roles, internal notes, admin flags, support records, partner data, tenant settings, configuration, or bulk object payloads.
How can runtime monitoring detect BOPLA risk?
Runtime monitoring can detect BOPLA risk by identifying sensitive response properties, excessive fields, unusual property changes, unexpected writable fields, schema drift, mass assignment indicators, and abnormal access to sensitive object attributes.
What SIEM context matters for BOPLA detection?
Useful SIEM context includes endpoint, method, caller, object type, property category, response status, sensitive data indicators, writable property indicators, risk score, API owner, related requests, and recommended action.
How should BOPLA findings be remediated?
BOPLA findings should be remediated by reviewing readable and writable properties, adding allowlists, enforcing field-level authorization, minimizing responses, separating internal and external models, adding regression tests, and validating runtime behavior.
What mistakes should teams avoid with BOPLA prevention?
Avoid returning full database objects, relying on frontend filtering, accepting arbitrary request properties, exposing internal fields, assuming object access means property access, skipping response inspection, and failing to monitor production behavior.
Reduce BOPLA risk with response visibility and property-level evidence
Ammune helps security teams and partners identify BOPLA risk with runtime API discovery, response property inspection, sensitive data exposure detection, schema drift monitoring, API abuse analytics, SIEM-ready events, risk scoring, API forensics, operational handover, managed detection, and executive reporting.