API-03 Broken Object Property Level Authorization

In this article, we will dive into the concept of Broken Object Property Level Authorization, which OWASP rates as the 3rd most prominent vulnerability in API security. We will explore the implications of Broken Object Property Level Authorization, potential risks, and effective measures to mitigate this vulnerability.

What is Broken Object Property Level Authorization?

Broken Object Property Level Authorization is a type of access control vulnerability that occurs when an API allows unauthorized users to view or modify specific properties of a resource. It is a merger of the mass assignment and information disclosure vulnerabilities from the previous OWASP API Security Top 10.

Understanding the Scope

When developers design APIs, they often start with a broad and open approach, allowing everything to be visible and editable. This flexibility enables them to design and iterate quickly. However, it also introduces the risk of leaving unnecessary properties accessible to unauthorized users.

The Impact of Broken Object Property Level Authorization

The severity of the impact depends on the specific API implementation. In some cases, broken property level authorization can lead to the disclosure of highly sensitive information, such as passwords or credit card details. Alternatively, it may expose properties that should not be public but do not pose a significant risk. It can also enable attackers to bypass security features, such as password confirmations.

Why is this an API Security Issue?

APIs are often created based on the final data storage rather than the underlying business logic. This approach, while providing flexibility during development, can result in the retention of overly permissive parameters and properties. Backwards compatibility concerns may also prevent the removal of certain properties, even if they are no longer necessary.

Resolving Broken Object Property Level Authorization

To address this vulnerability, developers can implement the following measures:

1. Utilize Framework Protections: Take advantage of the protections offered by your framework, such as the fillable method, to define which properties are editable and which are not.
2. Validate Returned Properties: Make sure that the properties returned by the API are used in the final user interface. Remove any parameters created for flexibility but are not required.
3. Avoid Default Data Storage: Do not rely on default values from data storage. Instead, carefully control what information is exposed through the API.
4. Avoid Generic Input Binding: Refrain from writing generic methods that automatically bind input to API resources. While this may save development time, it can introduce authorization issues.
5. Implement Password Confirmation: For sensitive actions, such as changing passwords, always require password confirmation to prevent unauthorized access.