What is Broken Object Property Level Authorization?
OWASP API3:2023 – Broken Object Property Level Authorization (BOPLA) arises when an API correctly validates access to an object but fails to enforce authorization at the property (field) level within that object.
As APIs increasingly rely on automatic serialization, object mappers, flexible query models, and rapid iteration cycles, field-level exposure has become a systemic architectural risk.
When property-level controls are missing, APIs may:
- Expose sensitive internal data fields
- Accept modification of server-controlled properties
- Enable privilege escalation or business logic abuse
- Introduce silent compliance and financial risk
Broken Object Property Level Authorization is subtle, common in modern frameworks, and often undetected, making it one of the most dangerous API security risks.
API3 vs API1: Understanding the Real Difference
The confusion between API1:2023 – Broken Object Level Authorization (BOLA) and API3:2023 – Broken Object Property Level Authorization (BOPLA) is common because both are authorization failures, but they operate at different layers of access control.
API1:2023 – Broken Object Level Authorization (BOLA):
BOLA occurs when an API fails to verify whether a user is authorized to access a specific object. The system checks authentication but does not properly enforce ownership or access control at the resource level, allowing unauthorized access to entire records.
For example, a user changes /api/orders/1001 to /api/orders/1002 and is able to access another customer’s order because the API does not verify ownership of the object.
API3:2023 – Broken Object Property Level Authorization (BOPLA):
BOPLA occurs when an API allows access to or modification of specific fields within an authorized object without validating whether the user has permission for those individual properties. The object access is valid, but field-level restrictions are missing or improperly enforced.
Vector 1 – Mass Assignment (Write):
A user updates their profile via PATCH /api/users/me with a legitimate payload to change their phone number. The API accepts the request but does not restrict which fields can be modified. The user injects additional fields:
JSON
{
“phone”: “+1-800-555-0199”,
“address”: “123 New Street, Austin TX”,
“kyc_verified”: true,
“kyc_level”: 2
}
The backend binds all incoming fields directly to the user object without checking whether kyc_verified or kyc_level are write-protected. The user bypasses the KYC process entirely, gaining access to higher transaction limits or features reserved for verified accounts.
Vector 2 – Excessive Data Exposure (Read):
The same GET /api/users/me endpoint returns more than the user needs to see their own profile:
{
“name”: “John Doe”,
“email”: “john.doe@example.com”,
“address”: “123 New Street, Austin TX”,
“kyc_level”: 2,
“kyc_verified”: true,
“risk_score”: 74,
“fraud_flag”: false,
“internal_review_notes”: “Flagged for address mismatch. Manual review pending.”
}
The user can see their own risk score, fraud flag status, and internal review notes. None of this should be visible. An attacker who knows their account is flagged can delay behavior until the review clears, or use the risk_score field to test how close they are to triggering an alert.
Both vectors exist on the same endpoint. The address update is legitimate. Everything else is not. The API had no property-level access control to separate what a user can read from what the system uses internally.
Why Broken Object Property Level Authorization (BOPLA) Occurs
The vulnerability emerges when systems control access to resources but fail to control access to the data inside those resources.
Below are the primary systemic causes.
1. Over-Reliance on Framework Serialization
Modern backend frameworks prioritize developer productivity. They automatically convert database entities into JSON responses and map incoming request bodies directly into internal objects. Convenient, but this creates a structural risk.
When full database models are serialized by default, internal fields are exposed unless explicitly excluded. Sensitive attributes end up in API responses without any deliberate intent. The application leaks more data than the business function requires.
The root cause is the absence of deliberate response shaping. Most systems return entire ORM entities (ORM, or Object-Relational Mapping, is the layer that translates database rows into code objects) instead of purpose-built response objects. Security then depends on developers remembering to manually exclude fields. As the model evolves, new fields get added and automatically become exposed. Code reviews rarely track field-level exposure changes.
This does not scale. In growing systems, accidental data exposure stops being a possibility and becomes a certainty.
2. Lack of Field-Level Access Control Policies
Most applications implement authorization at two levels:
- Endpoint level (Who can call this API?)
- Object level (Can this user access this record?)
Very few implement authorization at Property level (Can this user access this specific field?).
This gap exists because traditional access control models were designed around resources, not attributes.
For example, a system may correctly verify that a user can access their own account object. However, inside that object there might be risk scoring metrics, fraud flags, administrative notes, privilege indicators and other internal workflow states.
If the system does not explicitly validate field-level permissions, these properties are exposed simply because they belong to the object.
The architectural mistake is assuming that object ownership implies full property visibility. It does not.
3. Implicit Trust in Client-Side Controls
Another common cause is treating the frontend(UI) as an enforcement layer.
Some systems send complete objects to the client and rely on the UI to hide sensitive fields, disable editing of restricted properties and suppress internal data from display.
This is presentation logic. Attackers interact directly with API endpoints, inspect raw JSON responses, modify request payloads manually and replay and tamper with traffic.
If sensitive properties are sent to the client at all, they are exposed. If the backend accepts fields without validating authorization, they are modifiable.
4. Mass Assignment Through Automatic Binding
Mass assignment vulnerabilities are a direct contributor to API3 vulnerabilities.
Many frameworks automatically bind incoming JSON fields to object properties. If a request contains:
{
“name”: “User”,
“role”: “admin”,
“verified”: true
}
And the system blindly maps this payload to a database model, it may update fields that were never intended to be user-controlled.
Without strict allowlists:
- Privilege flags can be escalated.
- Pricing or discount controls can be manipulated.
- Approval states can be bypassed.
- Internal workflow flags can be altered.
The vulnerability arises because authorization is incomplete. The system checks whether the user can update the object, but not whether they can update each individual property.
5. Increased Attack Surface in GraphQL and Flexible APIs
Flexible API architectures increase exposure risk.In REST, the backend usually defines fixed response structures.
In GraphQL and similar flexible query systems, clients can request arbitrary fields, nested relationships, deep object hierarchies, related object attributes and more. This increases complexity significantly.
When authorization checks are not applied per field and per resolver, sensitive nested properties become queryable, internal relationships get exposed, and deep object traversal reveals data structures that were never meant to be visible.
GraphQL does not automatically enforce field-level authorization. Developers must explicitly implement it. If they assume schema design equals access control, they create systemic exposure.
How to Detect Broken Object Property Level Authorization (BOPLA)
BOPLA vulnerabilities are easy to miss in code review because the problem is not always a missing check. Sometimes it is a response that returns too much, or an endpoint that accepts fields it was never supposed to. Detection requires looking at both directions: what the API accepts and what it gives back.
Key Detection Techniques
- Analyze API Responses (Excessive Data Exposure): Inspect API responses to see if the API returns more properties than necessary, including sensitive data that a user should not see.
- Mass Assignment Testing (Unauthorized Modification): Submit API PUT or POST requests that include unexpected or sensitive parameters, such as adding “is_admin”: true or “role”: “admin” to a user profile update request.
- Parameter Fuzzing: Utilize tools like Arjun, Param Miner, or ffuf to inject hidden parameters and observe if the application accepts and updates them.
- Contrast User Roles: Compare responses of a low-privileged user against an administrator to detect if sensitive properties are exposed or editable by the lower-level user.
- Use Automated Tools: Leverage SAST/DAST scanners to identify mass assignment and data exposure vulnerabilities, which can be integrated into CI/CD pipelines.
Key Indicators of Vulnerability
These are the signals that confirm a BOPLA vulnerability is present, not just suspected. A single indicator is worth investigating. Two or more on the same endpoint is a finding.
- Unauthorized Modification Succeeds: The API accepts input for fields the user should not have access to modify (e.g., address without completing KYC).
- Excessive Data Exposure: The JSON response includes sensitive internal properties (e.g., balance, socialSecurityNumber).
- Improper Input Validation: The backend automatically binds all incoming JSON parameters to database objects.
Common Examples to Test
These are the test cases that surface BOPLA most reliably in real applications. Start with profile update endpoints since they tend to have the widest field exposure.
- Updating Profile: Change {“username”: “test”} to {“username”: “test”, “role”: “admin”}.
- Changing Password: Adding password_hash to a profile update request.
- Adjusting Scores/Values: Modifying a score or balance property that should be read-only.
How to Prevent BOPLA
BOPLA can be prevented by ensuring your API only exposes or accepts data specific to a user’s role and requested action. Implement strict input validation, use allowlists (DTOs/schemas) to restrict modifiable fields and enforce granular authorization checks for every property rather than just the object.
- Implement Schema-Based Validation: Use Data Transfer Objects (DTOs) or input schemas to strictly define which fields can be updated or read. Avoid passing raw, unsanitized input objects directly to database models.
- Enforce Field-Level Authorization: Check if the user has permission to read or write specific properties, not just the object itself. For example, a user may view their profile (GET /user/1) but not the is_admin property.
- Use Allowlisting (Not Blocklisting): Explicitly list permitted fields. Any field not on the list should be ignored or rejected, preventing unauthorized modifications (Mass Assignment).
- Avoid Generic Data Binding: Do not use to_json() or automatic binding methods that map all client-side inputs to backend data structures. Explicitly map only the required fields.
- Adopt Principle of Least Privilege: Ensure users only have access to the specific data properties necessary for their tasks.
- Use Non-Guessable Identifiers (GUIDs/UUIDs): While this primarily helps with BOLA, using unpredictable IDs for resources limits the ability to easily guess or iterate through objects.
- Regular Testing & Security Audits: Conduct regular penetration testing and automated API security scans to detect potential data exposure.
By combining these methods, specifically focusing on data validation at the property level and limiting data exposure to the bare minimum, you can effectively prevent this class of vulnerabilities.
