API Pentesting: Broken Object Property Level Authorization

Basics of Broken Object Property Level Authorization

Imagine you’re buying a movie ticket online. You fill out a form with your name, email, and payment details. But when you peek at the API response, it casually discloses the theater’s entire financial report, employee salaries, and a list of unreleased movies. Oops! That’s what is Broken Object Property Level Authorization. Let’s dive into it.

API Penetration Testing

The Basics of Broken Object Property Level Authorization

What’s happening?

Broken Object Property Level occurs when an API exposes or allows unauthorized changes to specific object properties that should remain private or restricted. It’s like giving a customer not just their ticket but the manager’s keys, access to the cash register, and a backstage pass — all unintended and dangerous.

BOPLA is basically the combination of Excessive Data Exposure (API 3: 2019) and Mass Assignment (API 6: 2019).

Why It Happens?

Let’s understand it using 2 examples, one related to excessive data exposure and the other related to mass assignment.

Example 1:

Request:
{
  "name": "John Williams",
  "email": "johnw@hack.com",
  "payment": "CARD-1234-2345-3456-4567"
}

Response:
{
  "message": "Ticket booked successfully",
  "Total Revenue Generated": "345298",
  "Discount Coupon_1": "50-OFF",
  "Discount Coupon_2": "80-OFF",
  "Booking Agent Name:": "Richard K",
  "Booking Agent ID": "E45262", 
  "Total Available Seats": "23",
  "Total Booked Seats": "45"
}

In the example above, the API was supposed to do one simple job: confirm John’s ticket booking with a simple message “Ticket Booked Successfully”. Instead, it spilled the beans on sensitive internal data like total revenue, discount codes, and even the booking agent’s information.

Example 2:

Ideal Request:
{
  "name": "John Williams",
  "email": "Johnw@hack.com",
  "password": "securepassword123"
}
Malformed Request:
{
  "name": "John Williams",
  "email": "Johnw@hack.com",
  "password": "securepassword123",
  "role": "Admin"
}

Ideally, the API endpoint should only accept parameters like name, email, and password. However, in the malformed request above, an additional parameter, "role": "admin", sneaks in. If the backend blindly accepts and processes this extra parameter—granting admin rights in the process—it’s a clear case of mass assignment.

This happens because the backend fails to validate and restrict the user-supplied properties to only what’s explicitly allowed. By leaving the door open for unexpected input, the API unintentionally gives users far more control than intended.

Now, how does this example relate to Broken Object Property Level Authorization? The answer is straightforward. Every object — whether it’s a user, a booking, or any other entity — has its own set of properties. For a user, these properties might include name, email, password, address, role, and contact number.

Not all these properties should be accessible or modifiable directly by the user, nor should they be exposed to others (sometimes, not even to the user themselves).

In the earlier example, we saw how a user was able to change their role, which ideally should never be modifiable by a regular user. Similarly, in the other example, the API response disclosed additional unnecessary details, revealing sensitive properties that shouldn’t have been visible to anyone.

Both cases highlight Broken Object Property Level Authorization, as the API failed to enforce strict controls over which properties can be accessed or modified by whom.

How to Test for Broken Object Property Level Authorization

As a bug bounty hunter or pentester, here’s your playbook:

1. Inspect API Responses: Look for sensitive properties in the data returned by the API.
2. Attempt Unauthorized Property Modification: Try changing properties you shouldn’t have access to and observe the API’s response.
3. Fuzzing: Send unexpected or random data to API endpoints to discover hidden properties or behaviors.
4. Role Variation Testing: Test the API with accounts of different roles to see if property-level permissions are enforced consistently.

Impact: Imagine unauthorized users elevating their privileges, accessing sensitive data, or modifying critical properties like account balance, user roles, or billing information.

Severity: The severity typically ranges from High to Critical, depending on the sensitivity of the exposed or modifiable properties.

Fixing Broken Object Property Level Authorization

1. Implement Property-Level Access Controls: Ensure that users can only access and modify properties they’re authorized to interact with.
2. Limit Data Exposure: Return only the necessary data in API responses to minimize the risk of exposing sensitive properties.
3. Input Validation: Validate incoming data to ensure users aren’t modifying properties they shouldn’t.
4. Regular Security Audits: Conduct periodic reviews of API endpoints to identify and address potential BOPLA vulnerabilities.

Wrap-Up

Broken Object Property Level Authorization might sound like a mouthful, but it boils down to one key idea: control. APIs must keep a tight leash on what properties users can access or modify. Failing to do so opens the door to privilege escalations, sensitive data leaks, and malicious exploits.

As a bug bounty hunter or pentester, always question what’s hiding behind the scenes in API requests and responses. Is the API exposing more than it should? Can you sneak in an extra property and get away with it? These small oversights can have massive consequences.

hackerdevil

Stay safe, stay informed, and keep coming back for more empowering insights.

Thank You for reading. Knowledge is power, so keep gaining!!