LAST UPDATED April 2, 2024
Number 3 on the 2023 OWASP API Security Top 10 list, Broken Object Property Level Authorization is a new 2023 addition and combines two entries on the 2019 list: Excessive Data Exposure and Mass Assignment. OWASP made this change to focus on the root cause of these two vulnerabilities: the lack of or improper authorization at the object property level. This can lead to unauthorized parties getting access to or manipulating sensitive data.
OWASP says of this vulnerability,
“An API endpoint is vulnerable if:
- The API endpoint exposes properties of an object that are considered sensitive and should not be read by the user (previously named: “Excessive Data Exposure”).
- The API endpoint allows a user to change, add/or delete the value of a sensitive object’s property which the user should not be able to access (previously named: “Mass Assignment”).”
ISACA explains that “this vulnerability occurs when a user without validated access permissions exploits the endpoint by reading and/or modifying the value of objects. The ability to update object elements allows for mass assignment, which is an input and authorization validation flaw that allows attackers to manipulate client-provided data for advanced exploits. Excessive data exposure may occur if nonessential data are revealed.”
The difference between this vulnerability and Broken Object Level Authorization (BOLA) (number 1 on the list) is that BOLA refers to authorization to access a whole object, Broken Object Property Level Authorization goes one level deeper – and refers to authorization to access a property within an object.
Examples of Broken Object Property Level Authorization
If your developers name calls for human readability, they might, for instance, implement something like: /api/getAddress /{userId}/
A clever attacker might already see a potential pattern here, and might try:
…/api/getSSN /{userId}/
…/api/getSocialSecurityNumber/{userId}/
…/api/getSocial/{userId}/
If the application stored this sensitive piece of PII (pro-tip, it shouldn’t), an attacker might guess their way to an undocumented API call, and through that recon, they might gain access to PII.
Another example: Imagine an application containing an API endpoint allowing authorized users to update user information. This API functionality may have been intended for corporate accounts who need to make updates in bulk to coincide with personnel changes.
<pre>
<code>
POST /posts/bulkupdate
{ “data”: [
{
“user_id”: 123789,
“title_id”: “VP of Sales”,
“email”: “sales.vp@company.com,
…
}, …
] }
</code>
</pre>
But imagine this innocuous bulk-update were to be used by a malicious individual intent on causing mischief or worse:
<pre>
<code>
POST /posts/bulkupdate
{ “data”: [
{
“user_id”: 123789,
“title_id”: “VP of Sales”,
“email”: “attacker@nefarious.com”,
…
}, …
] }
</code>
</pre>
In this hypothetical example, the attacker modifies the “email” property in order to update the user’s email to an attacker owned inbox. If the updated account has elevated permissions within the application and the attacker leverages the password reset functionality to send an updated password to their inbox, they now have elevated permissions within the application.
Preventing Broken Object Properly Level Authorization
Prevention starts with defensive programming techniques, such as enforcing a standardized authorization strategy within all endpoints of your API, taking into account the user authorization level and the authorization requirements of all referenced resources, and rigorously maintaining security policies controlling which fields are editable (“allowlists”).
It’s a common practice when building APIs for developers to simply serialize all the data related to a particular API resource, irrespective of that data’s sensitivity. This practice may seem like a common sense time-saving design pattern, but it can result in an info leak, where sensitive data is exposed to unauthorized clients, or bad actors. A more defensive practice is to clearly classify data in a system, and to define a separate data model for public interfaces such as APIs.
Bottom line for developers: Be conservative about what data you return in API responses. It might seem like a great idea to “future-proof” an API, making it applicable for applications that were not originally envisioned by the application owner. Instead, be conservative in resource representations and only include data necessary for well-understood use cases. This conservative approach dramatically decreases implementation effort, and also presents less attack surface that bad actors can use to map, undermine, and exploit your API.
How ThreatX Can Help
It can be difficult to detect if an attacker has exploited an instance of this vulnerability because the application would show no signs of an error. However, ThreatX continuously monitors each unique client/user and would detect probing/reconnaissance activity targeting this vulnerability. Other suspicious activity, such as repeated error responses, typically indicate an attacker is up to no good. If these behaviors reached a certain risk threshold, or are observed in conjunction with other suspicious attacker behavior (which they frequently are), we would block the attacker and record the events for later review.
ThreatX also addresses threats that arise from exploitations at the OS level with its Runtime API and Application Protection (RAAP). This solution monitors and protects from the inside, at the operational side of your APIs and apps.
Learn more about ThreatX RAAP.
Finally, ThreatX provides visibility on potentially vulnerable API endpoints through several data points. First, the details for each attack are correlated to each endpoint targeted. Second, failed requests are analyzed for various error conditions that indicate potential vulnerabilities.
How Our Approach Is Unique
Real-Time Blocking
Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify an attacking IP, but require security teams to try to model the complex behavior in a third-party WAF (or try to block one IP at a time after the fact).
ThreatX doesn’t just tell you about your API vulnerabilities or attempted attacks; we also block API attacks in real-time – from the edge to runtime.
Learn more about ThreatX’s real-time blocking.
ThreatX recognizes attacker behavior indicative of an attempt to exploit broken object property level authorization, then flags and watches that user. This real-time monitoring enables ThreatX to execute advanced threat engagement techniques, such as IP interrogation, fingerprinting, and tarpitting. When a series of user interactions cross our default (or your customized) risk threshold, we block the attack.
Less False Positives
As risk rises, ThreatX immediately blocks an attack – stopping the threat in its tracks. ThreatX’s blocking modes are designed to block malicious requests and deter suspicious entities from attacking your APIs, while allowing benign traffic and real users through. Legacy WAFs struggle with false positives because they only make blocking decisions based on rules, but attackers and legitimate users don’t always follow the rules. Sometimes a legitimate user who forgot their password looks like an attacker, and sometimes an attacker cycling through usernames and passwords looks like a legitimate user. ThreatX can tell the difference.
Learn more about the 2023 OWASP API list.
