OWASP Top 10 API security risks: Broken object property level authorization

Number three on the draft list of the Open Worldwide Application Security Project® (OWASP) Top 10 API Security Risks is broken object property level authorization.

Broken object property level authorization is new to the list in 2023, but it incorporates two items from the 2019 release, excessive data exposure and mass assignment. Excessive data exposure includes exposure of sensitive properties during a read operation, while mass assignment allows attackers to change properties during a write operation.

Combined, these flaws allow attackers to access an object’s property without first validating access permissions and make malicious changes.

Attack vectors

Attackers exploit API endpoints by gaining access and reading or changing the value of object properties that they should not be able to access. Attack vectors occur because object properties are not adequately protected, requiring access validation for object properties or properties that are not filtered to return only specific information.

In this case, the API endpoint allows users to access, add, delete, or change the value of sensitive objects that attackers should not be able to access.

OWASP assigned an exploitability score of three, meaning it is somewhat exploitable by hackers.

Security weaknesses

API authorization should be done in layers, providing multiple protections against attack. While developers generally require validation to ensure users can access functions and specific objects, they may fail to validate whether users can access specific properties within the object.

OWASP scores broken object property level authorization as a two on their scale of prevalence and detectability, denoting that the vulnerability is commonplace and can be detected with a moderate effort.

Business impacts

When attackers can modify sensitive object properties, it can lead to data breaches, loss, and data manipulation, creating significant business risks. Abusing weak access control and logic flaws can lead to substantive exposure, including sensitive data and privilege escalation.

How broken object property level authorization works

When users make requests, it returns relevant objects. Without gatekeeping on which items are returned, it can lead to excessive data dumps. While validated users may ignore additional object properties, attackers may use the information to breach systems or escalate privileges.

Developers often assume that APIs will only be accessed by validated users, leaving vulnerabilities when APIs are accessed directly by attackers. This allows access to excess data or the ability to overwrite server-side variables not intended.

Common causes include framework-level autobinding and parsing requests as objects. Copying objects is easier than selecting specific values within the object and can save time in coding, but it can expose data to threat actors.

Real-world examples

There have been several high-profile real-world examples, including the breach of Twitter in July 2022. Data from more than 5 million Twitter users was for sale on a hacker forum, and data from another 400 million users was available on the dark web. In January 2023, another attack on the social media platform led to a ransomware request to prevent the exposure of 235 million user records.

HealthEngine was fined $2.9 million after the exposure of 59,000 patient records containing personally identifiable information.

GitHub was also hacked using broken object property level authorization. A researcher used a mass assignment exploit to add a public key to a Ruby on Rails repository, gain admin privileges, and commit files to project accounts.

Detecting broken object property level authorization vulnerabilities

Detecting broken object property level authorization should be part of security audits of authentication mechanisms. Vulnerability scanners may identify common API security threats, and manual testing may be required to identify broken object property level authorization vulnerabilities.

Developers should test API endpoints for:

• Excessive data exposure: Is more data returned from objects than was requested?
• Mass assignment: Can users initialize or overwrite server-side variables that are not intended by the application?

Preventing broken object property level authorization vulnerabilities

When exposing any object using an API endpoint, developers should always add validation measures to ensure that only validated users have access.

Deploy specific object properties

Avoid generic methods such as _json() and to_string(). Instead, provide specific object properties that should be returned. Define all parameters and payloads.

Avoid mass assignment

Whenever possible, avoid mass assignment using functions that automatically bind client input into code variables, internal objects, or object properties. Further, developers should not rely on clients to filter data and hide fields, only returning the specific properties that are requested.

Use schema-based response validation

By implementing a schema-based response validation, developers can add a security layer, defining and enforcing all data returned during API requests. Use read-only properties set to true in the object schema for any properties that can be retrieved through an API but should not allow modification.

Minimal functional requirements

Limit returned data structure to minimal levels needed for business and functional requirements for API endpoints.

Enforce response checks

Enforce response checks to prevent accidental leaks of data, including exceptions and error responses.