API3:2023 - Broken Object Property Level Authorization

Broken Object Property Level Authorization occurs when an API allows users to read or modify sensitive object properties without proper authorization checks.

What is an object property?

In APIs, an object is a resource such as a user, file, or order. An object property is any field belonging to that resource.

{
  "id": 1,
  "name": "report.pdf",
  "owner": "user-123",
  "is_public": false
}

Some properties are safe for users to control (like name), while others are security-sensitive (like owner or is_public) and must be controlled by the server.

API1 (BOLA):
→ Wrong object

API3:
→ Correct object, wrong properties

• Attackers can escalate privileges without changing identity
• Sensitive properties can be overwritten
• Hidden data can be exposed
• Security boundaries can be bypassed silently

Why it is hard to detect

• Endpoints behave normally under expected inputs
• Vulnerable fields are often undocumented
• Issues only appear with crafted payloads
• Standard tests rarely include hidden fields

As a result, these vulnerabilities frequently survive into production.

This vulnerability appears when APIs map client input directly to internal object properties without filtering or validation.

# vulnerable
file = File(**request.json)
db.save(file)

# secure
file = File(
  name=request.json["name"],
  owner=current_user.id
)

Two types of API3 issues:

Read exposure:
→ Hidden fields returned in responses

Write abuse:
→ Protected fields modified by user input

Attacker perspective

• Inject unexpected fields into requests
• Override ownership or permissions
• Toggle visibility flags
• Compare responses for differences

A common example is abusing object properties in file upload flows.

{
  "name": "file.txt",
  "owner": "admin",
  "is_public": true,
  "object_id": 1
}

The attack primarily abuses protected fields such as owner and is_public.

In this scenario, control over object_id further amplifies the impact by targeting existing sensitive objects.

In real systems, similar issues appear in PATCH, PUT, and profile update endpoints.

• Whitelist allowed fields explicitly
• Never bind entire request objects directly
• Separate DTO and internal models
• Enforce field-level authorization rules

allowed_fields = ["name"]

clean_input = {
  k: v for k, v in request.json.items()
  if k in allowed_fields
}

Field classification strategy

• User-controlled: name, description
• Server-controlled: owner, role, tenant_id
• Sensitive/internal: flags, permissions, IDs

Only user-controlled fields should be accepted from client input.

• Inject unexpected fields
• Modify ownership or roles
• Test PATCH/PUT endpoints
• Compare responses for hidden fields

If modifying a field changes behavior or reveals new data, the API is vulnerable.

Broken Object Property Level Authorization is subtle but critical.

If users can control fields they should not control, the API is vulnerable.

Every field must have an explicit access rule.