.svg)
2023 OWASP API Top Ten
.png)
TLDR Key Takeaways
The Open Web Application Security Project (OWASP) is a highly regarded non-profit organization represented by thousands of members worldwide. The foundation promotes best practices in web application security, codifies industry standards, and produces freely available articles, methodologies, documentation, tools, and technologies to help developers keep their data safe.
In 2019, OWASP added the API Security Top 10 list to their annual reports. The list serves as a standard awareness document for software development of the security issues they must address. The list was upgraded in 2023, adding a couple more security issues while combining older ones.
Current API Security Top 10
#1: Broken Object Level Authorization
Broken request validation allows an attacker to perform an unauthorized action by reusing an access token
#2 Broken Authentication
Broken user authentication allows attackers to impersonate legitimate users
#3 Broken Object Property Level Authorization
The lack of or improper authorization validation at the object property level.
#4 Unrestricted Resource Consumption
Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources.
#5 Broken Function Level Authorization
Broken request validation allows an attacker to execute functions they are unauthorized to access
#6 Unrestricted Access to Sensitive Business Flows
APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner.
#7 Server Side Request Forgery (SSRF)
Occur when an API is fetching a remote resource without validating the user-supplied URI.
#8 Security Misconfiguration
Insecure configurations, including misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and error messages containing sensitive information
#9 Improper Inventory Management
Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements.
#10 Unsafe Consumption of APIs
In order to compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.
What changed from 2019?
Added Broken Object Property Level Authorization
Broken Object Property Level Authorization (BOPLA) combines two items from the 2019 OWASP API Security Top Ten: excessive data exposure and mass assignment.
Excessive Data Exposure occurs when an API provider responds to a request with an entire data object. Usually, an API provider will filter out the data object down to what is being requested. When the data object is shared without being filtered, there is an increased risk of exposing sensitive information.
Mass Assignment is a weakness allowing user input to alter sensitive object properties. If, for example, an API uses a special property to create admin accounts, only authorized users should be able to make requests that successfully alter those administrative properties. If there are no restrictions in place, an attacker can elevate their privileges and perform administrative actions.
These vulnerabilities involved issues with object property authorization, which were combined under the new Broken Object Property Level Authorization title.
Example: A dating app allows users to report other users for inappropriate behavior. As part of this flow, the user clicks on a "report" button, and the following API call is triggered:
POST /graphql
{
"operationName":"reportUser",
"variables":{
"userId": 313,
"reason":["offensive behavior"]
},
"query":"mutation reportUser($userId: ID!, $reason: String!) {
reportUser(userId: $userId, reason: $reason) {
status
message
reportedUser {
id
fullName
recentLocation
}
}
}"
}
The API Endpoint is vulnerable since it allows the authenticated user to have access to sensitive (reported) user object properties, such as "fullName" and "recentLocation" that are not supposed to be accessed by other users.
Added Unrestricted Resource Consumption
Unrestricted Resource Consumption is an API issue where the API provider does not have safeguards to prevent excessive API use. When there are no restrictions for resource consumption, the API provider could become a victim of Denial of Service (DoS) attacks or experience unnecessary financial costs. Unrestricted Resource Consumption is an updated version of API4:2019 Lack of Resources and Rate Limiting.
Example: A social network implemented a “forgot password” flow using SMS verification, enabling the user to receive a one-time token via SMS to reset their password.
Once a user clicks on "forgot password," an API call is sent from the user's browser to the back-end API:
POST /initiate_forgot_password
{
"step": 1,
"user_number": "6501113434"
}
Then, behind the scenes, an API call is sent from the back-end to a 3rd party API that takes care of the SMS delivering:
POST /sms/send_reset_pass_code
Host: willyo.net
{
"phone_number": "6501113434"
}
The 3rd party provider, Willyo, charges $0.05 per this type of call.
An attacker writes a script that sends the first API call tens of thousands of times. The back end follows and requests Willyo to send tens of thousands of text messages, leading the company to lose thousands of dollars in minutes.
Added Unrestricted Access to Sensitive Business Flows
Unrestricted Access to Sensitive Business Flows represents the risk of an attacker being able to identify and exploit API-driven workflows. An attacker can leverage an organization's API request structure to obstruct other users if vulnerable. This obstruction could result in spamming other users, depleting the stock of highly sought-after items, or preventing other users from using expected application functionality. This is a new addition to the 2023 top ten list.
Example: A technology company announces releasing a new gaming console on Thanksgiving. The product has a very high demand, and the stock is limited. An attacker writes code to buy the new product and complete the transaction automatically.
On the release day, the attacker runs the code distributed across different IP addresses and locations. The API doesn't implement the appropriate protection and allows the attacker to buy most of the stock before other legitimate users.
Later, the attacker sells the product on another platform for a much higher price.
Added Server Side Request Forgery (SSRF)
Server Side Request Forgery is a vulnerability when a user can control the remote resources retrieved by an application. An attacker can use an API to supply their input, in the form of a URL, to control the remote resources retrieved by the targeted server.
An attacker could supply URLs that expose private data, scan the target's internal network, or compromise the target through remote code execution. SSRF is also number 10 on the 2021 OWASP Top 10 list and is a growing threat to APIs.
Example: A social network allows users to upload profile pictures. The user can choose either to upload the image file from their machine, or provide the URL of the image. Choosing the second, will trigger the following API call:
POST /api/profile/upload_picture
{
"picture_url": "http://example.com/profile_pic.jpg"
}
An attacker can send a malicious URL and initiate port scanning within the internal network using the API Endpoint.
{
"picture_url": "localhost:8080"
}
Based on the response time, the attacker can determine whether the port is open.
Added Unsafe Consumption of APIs
Unsafe Consumption of APIs is the only item on the top ten list that focuses less on the risks of being an API provider and more on the API consumer. Unsafe consumption is a trust issue. When an application consumes the data of third-party APIs, it should treat those with a similar trust to user input. There should be little to no trust. So, data consumed from third-party APIs should be treated with similar security standards as end-user-supplied input. If a third-party API provider is compromised, that insecure API connection back to the consumer becomes a new vector for the attacker to leverage. In the case of an insecure API connection, that could mean the complete compromise of organizations insecurely consuming data from that provider.
Example: An API relies on a third-party service to enrich user-provided business addresses. When an address is supplied to the API by the end user, it is sent to the third-party service, and the returned data is then stored on a local SQL-enabled database.
Bad actors use the third-party service to store an SQLi payload associated with a business they created. Then they go after the vulnerable API, providing specific input that makes it pull their "malicious business" from the third-party service. The SQLi payload is executed by the database, exfiltrating data to an attacker's controlled server.
More Resources
Learn More About API Security
Similar Posts
.webp)