Broken object property level authorization

Broken object property level authorization occurs when an API fails to enforce proper access control for individual object properties. This can lead to unauthorized disclosure or modification of sensitive data. Such vulnerabilities arise when APIs expose more data than necessary (excessive data exposure) or fail to validate user permissions when modifying object properties (mass assignment). Attackers exploit this by inspecting API responses, crafting malicious requests, and manipulating object properties.

In this lesson, you will learn how broken object property level authorization vulnerabilities occur, how attackers exploit them, and how to secure your APIs. This includes an engaging scenario demonstrating the vulnerability, an under-the-hood technical breakdown, and mitigation strategies.

Let's take a look at a fictitious vacation rental company. We have access to their API and want to do some exploring... or testing

In the example above, the API lacked schema validation, exposing sensitive properties like admin_notes and payment_token. Attackers exploit this using tools to inspect JSON responses. The API’s /update endpoint also failed to restrict which properties could be modified, allowing unauthorized changes to critical properties like total_price and user_role.

This JavaScript example demonstrates a vulnerable API endpoint that exposes sensitive data due to unrestricted access to object properties. The endpoint at /api/booking/details retrieves a booking object using the getBooking function and sends it as a JSON response using res.json(booking) without any filtering or validation of the data being returned.

This approach is dangerous because it exposes sensitive fields that should remain hidden, such as payment details or personal identifiers. By failing to sanitize or filter the returned object, the application risks leaking confidential information to unauthorized users, violating data protection principles.

The Python example shows an endpoint at /api/booking/update that allows updates to booking objects. The code retrieves a booking object using get_booking and iterates over the key-value pairs in the request payload, dynamically setting object attributes with setattr.

This approach is highly insecure because it lacks validation of the fields being updated. Malicious actors can modify sensitive properties or inject unexpected data, potentially bypassing access control checks or corrupting the object. By allowing unrestricted updates, the endpoint creates significant risks to the integrity and security of the data.

This PHP code snippet demonstrates unrestricted updates using a JSON payload. It iterates through the input data and uses $booking->$key = $value to assign values directly to the corresponding booking properties.

This implementation is vulnerable to mass assignment attacks, where an attacker can set arbitrary properties, including sensitive ones like price, status, or role fields. Without filtering or validating the input data, this code allows attackers to manipulate the booking object in unintended ways, leading to unauthorized actions or data corruption.

The C# code handles booking updates using a Dictionary<string, object> for incoming updates. It iterates over the dictionary keys and uses reflection with GetType().GetProperty(key) to dynamically update object properties without any validation or access control.

This approach is insecure because it permits arbitrary updates to the booking object. An attacker could exploit this by modifying sensitive or restricted fields. The lack of field validation and access control checks creates vulnerabilities that could lead to privilege escalation or data integrity issues.

The Java example showcases a /api/booking/update endpoint that updates booking properties dynamically using reflection. The code retrieves the booking object via bookingService.getBooking, then iterates over the provided key-value pairs to set object fields using Field.set. Errors such as NoSuchFieldException or IllegalAccessException are ignored, further increasing the risk.

This design is vulnerable because it allows unrestricted updates to any field of the Booking object, including fields that should be immutable or protected. Ignoring exceptions means even accidental or malicious tampering with internal fields may go unnoticed, amplifying the impact of this flaw.

The Go code implements a handler for updating booking details, which parses incoming JSON data into a map[string]interface{}. It uses reflection to dynamically set fields on the booking struct without any validation by calling structValue.FieldByName(key).Set().

This implementation is highly insecure as it allows arbitrary updates to any field of the booking struct, regardless of whether the field should be protected or restricted. Attackers could exploit this to modify sensitive data or corrupt the structure entirely. The lack of field validation or access control makes this code particularly dangerous in a production environment.

As we seen above, broken object property level authorization occurs when an application fails to properly enforce access controls on specific properties or fields of an object. This vulnerability can have severe consequences, leading to unauthorized data access, privilege escalation, financial fraud, reputation damage, compliance violations, and even system instability.

One major impact is unauthorized data access. Attackers may exploit this weakness to access sensitive information that should be restricted. For example, they could view private user details such as email addresses, phone numbers, or financial information. In some cases, they might gain access to confidential business data, including trade secrets or employee records.

Another significant risk is privilege escalation. When authorization checks are improperly enforced, attackers can modify properties they shouldn’t have access to, allowing them to elevate their privileges. For instance, an attacker could change a user’s role to gain administrative rights or alter permissions on a file or resource to grant themselves access.

Financial fraud is another potential consequence, like in the example above. Exploiting weak authorization controls, attackers could manipulate transactional data or financial records. For example, they might adjust the amount or recipient of a payment or modify billing and shipping information to redirect goods or services. Or get a rental for the low price of $50!

Finally, this vulnerability can lead to system instability. Unauthorized modifications to object properties may cause system malfunctions, data corruption, or service disruptions. For example, attackers might change critical configurations that affect system performance or inject invalid or malicious data that causes application errors.

Mitigating broken object property level authorization requires a combination of secure API design and careful implementation practices to ensure robust protection against unauthorized access.

A secure API design is essential to prevent unauthorized access to object properties. One effective approach is to use explicit allowlisting through schema validation, which defines the allowed properties for responses and updates. This ensures that only the intended fields can be accessed or modified. Additionally, adhering to the principle of least privilege is crucial; access should be restricted based on roles and permissions, ensuring users can only interact with the properties they are authorized to access. Furthermore, access control must be enforced at the property level by implementing checks that validate whether a user has the necessary permissions for each specific property.

Proper implementation details are equally important to safeguard against this vulnerability. Input validation should be performed rigorously, and property-level restrictions must be enforced to prevent unauthorized modifications. Developers should avoid using generic deserialization functions that automatically bind input to internal objects, as these can inadvertently expose sensitive properties. Logging and monitoring should also be implemented to detect and respond to unauthorized access attempts, providing an additional layer of security and visibility.

This JavaScript implementation improves security by limiting the data returned by the /api/booking/details endpoint. The res.json() method explicitly specifies only the fields id, user, and dates to be included in the response. Fields such as sensitive payment or administrative information are excluded.

This mitigation eliminates the risk of exposing sensitive data, as the output is tightly controlled. By filtering the returned properties, this code prevents unauthorized access to confidential fields.

The Python code secures the /api/booking/update endpoint by introducing an allowed_updates set containing only the permitted fields, dates and comments. The setattr function updates object attributes only if the field exists in allowed_updates.

This mitigation addresses the mass assignment vulnerability by explicitly allowlisting fields that can be updated. Attempts to modify unauthorized fields will be ignored.

The PHP implementation uses an $allowedKeys array to define fields that can be updated, restricting updates to dates and comments. The in_array function ensures that only these permitted fields are updated on the booking object.

This code eliminates the mass assignment vulnerability by enforcing an allowlist of allowed fields. Any unauthorized fields in the request payload are ignored. This approach effectively secures the endpoint, with no obvious weaknesses.

In this C# example, the UpdateBooking method accepts a BookingUpdateModel object containing only the allowed properties (Dates and Comments). The method explicitly checks whether these fields are present in the request and updates the booking object accordingly. Unpermitted fields cannot be passed in the BookingUpdateModel class, ensuring additional security at the data model level.

This implementation is secure, as it restricts updates to a predefined set of fields, both through explicit logic in the controller and by defining a strict data model.

This Java implementation secures the /api/booking/update endpoint using a BookingUpdateModel DTO that includes only the id, dates, and comments fields. The updateBooking method explicitly updates these fields if they are present in the DTO. Fields outside of the DTO cannot be modified.

This approach mitigates vulnerabilities by strictly controlling the updatable fields at both the controller and data model levels.

The Go example secures the updateBookingHandler function by defining a BookingUpdateModel struct with only the allowed fields (ID, Dates, and Dates). The handler explicitly checks these fields before updating the booking struct.

This code effectively mitigates vulnerabilities by enforcing strict field-level control through the BookingUpdateModel struct. It ensures that only permitted fields can be updated.

Mitigating this type of vulnerability in any language follows the same concept: explicitly control which fields can be updated or returned.

Learn more about broken object property level authorization with these resources:

• OWASP API Security Project: https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
• Snyk OWASP API Security Top 10 Risks