Modern application architecture consists of many components that communicate via APIs, which makes APIs indispensable to streamlining business processes, enhancing user experiences and promoting system interoperability. As reliance on APIs grows, securing them becomes increasingly vital. In this blog post, we discuss OWASP’s recently updated list of API security risks and highlight changes from the previous publication in 2019.
The OWASP Top 10 API Security Risks alerts developers and security professionals to the most critical risks in API design and implementation while providing essential guidance to protect digital assets and users’ sensitive information.
The OWASP API Top 10 Security Risks are rated according to the following criteria:
Based on these factors, OWASP ranks the top 10 risks as follows, with API1 inherently most critical:
API1:2023 – Broken Object Level Authorization
API2:2023 – Broken Authentication
API3:2023 – Broken Object Property Level Authorization
API4:2023 – Unrestricted Resource Consumption
API5:2023 – Broken Function Level Authorization
API6:2023 – Unrestricted Access to Sensitive Business Flows
API7:2023 – Server Side Request Forgery
API8:2023 – Security Misconfiguration
API9:2023 – Improper Inventory Management
API10:2023 – Unsafe Consumption of APIs
As we look at each security risk, we’ll show you how Prisma Cloud's WAAS module can fortify your API security to help you maintain the integrity of your business processes and sensitive data.
Broken Object Level Authorization (BOLA) is a security risk that occurs when an application fails to enforce authorization controls on an object. Without enforced authorization controls, an attacker can manipulate an object’s value in the request to access and alter objects they’re not authorized to interact with and possibly exfiltrate personal identifiable information (PII).
In the example below, an attacker modifies their unique ID to a different one and gains access to someone else’s data.
GET /users/current/info will return current user information.
But if an attacker has access to GET /users/42/info, then we have BOLA. The attacker will be able to access someone else’s data, which may contain secrets and PII.
Using Prisma Cloud’s WAAS API definition scan feature, users can identify issues in their OpenAPI or Swagger specification and fix them before adversaries exploit them.
Applications may not implement strong authentication mechanisms, which could give hackers easy access to forbidden data and functionalities. A broken authentication may allow attackers to compromise authentication tokens and even bypass authentication.
This can happen for various reasons — weak passwords, storing credentials in plaintext, not validating JWT tokens, allowing access to the data without authentication, etc.
WAAS protects users from this risk through features such as DoS protection, which enforces rate limiting and blocks credentials stuffing attacks, as well as API protection, which enforces authentication schemas.
Modern web applications communicate with the backend via API queries to retrieve data and populate the proper fields on the frontend pages. Such queries may return with complete object properties, which the frontend then filters and displays only the relevant information according to the appropriate columns.
But when such queries occur, excessive data could return from the backend. For example, if the frontend expects to receive object data with the user’s information — first and last name, perhaps — it may return from the backend with the user’s email address and social number. An attacker may query these APIs to receive the sensitive information and bypass the frontend's filters.
On the other hand, a hacker could manipulate business logic from their side by modifying form parameters. The attacker might add a key-value pair within the HTTP request to set and override an object's property. This should only be allowed for administrators due to insufficient server-side validation. But by adding is_admin:true as a key-value pair in the POST request, the attacker could escalate their privileges to an admin level, granting them access to perform actions reserved exclusively for administrators.
To address this, Prisma Cloud’s WAAS provides API protection parameters violation based on the Swagger or OpenAPI specification to ensure that the parameters received in the requests are as defined in the specification. Another helpful feature is the API Discovery that identifies if responses contain sensitive data.
Referred to as Lack of Resources and Rate Limiting on the 2019 OWASP 10 API Security Risks, Unrestricted Resource Consumption remains conceptually the same. API4:2023 occurs when an API doesn't properly limit the amount of resources that can be consumed by a single request or concurrent requests. Consumption might involve the amount of CPU required to process a request or the amount of memory or disk space required to store data returned by the request. Regardless, this can result in a denial of service (DoS) attack.
An attacker, for example, could change the number of products in the page. For the server to satisfy the request, it will allocate compute and storage resources. The bigger the size, the more resources it will allocate, which causes the API to return an excessive amount of products, consuming extensive resources and leaving none available for other users’ requests.
GET /products?page_size=1000000 HTTP/1.1
In a cloud-native environment, resources are dynamic and may not end in a DoS. Still, such an attack will elevate costs and greatly affect the organization.
WAAS protects users from this threat with its robust DoS protection. This security feature enforces rate limiting and effectively blocks attempts to overwhelm APIs with DoS attacks. Additionally, WAAS offers bot protection to identify and block illegitimate users from the website.
Broken Function Level Authorization (BFLA) can resemble BOLA, in that it allows users to access and control a function without validating the proper permissions. The main difference between them lies in the authorization level. While in BOLA the application should validate whether the user can and should access the specific object, in BFLA the validation is more generic and should occur on the function.
An attacker, for example, could have access to GET /api/comments/all to retrieve all the comments in the blog, but they shouldn’t have permission to retrieve comments made by the admin, which only the admin is allowed to execute via POST /api/admin/export.
WAAS users can defend themselves from BFLA risks using the Access Control feature of Prisma Cloud, which blocks malicious traffic from banned sources based on geo-location or specific countries.
Unrestricted Access to Sensitive Business Flows is more of a logical business flow risk. An attacker could potentially understand how some API requests may affect internal business workflow and exploit them in various ways.
For example, a malicious user may purchase all existing tickets to a popular musician show and resell them at a higher price due to the supply shortage they created. Another scenario could involve booking all the reservations for a restaurant, making sure no one can reserve a table, damaging the restaurant’s business.
Business logic flow issues are contextual and different for each application, which makes them difficult to detect. The most effective way to address them is by providing a strong security foundation at the application level.
Server Side Request Forgery (SSRF) occurs when an application uses a URI supplied by the user to interact with some services. Depending on the business logic, a specially crafted URI may allow an attacker to check for open ports or even communicate with known internal URIs to extract secrets and keys. In a cloud environment, the attacker’s success could have a disastrous impact and perhaps compromise the entire cluster.
A common scenario presenting this risk centers on a user uploading a profile image from their local computer. It’s usually possible to also insert an external URI to get the image, and attackers can exploit this by entering an internal address and forcing the table to query them and get sensitive data. SSRF impact may vary due to the nature of the application architecture and business logic.
A range of misconfigurations can challenge API security and introduce risk. These include:
For example, Cache-Control HTTP header instructs browsers, caching servers and proxies on whether to cache the resource and in which conditions to do so. A resource that contains secrets and sensitive information should be configured with header Cache-Control: no-cache on the response to prevent browsers, caching servers and proxies from caching the resource. Without this precaution, hackers could retrieve the content of the resource, including sensitive information, by requesting the resource directly from the cached server.
The complexity of modern web applications require proper inventory management to securely maintain the system. In a cloud-native environment with myriad moving components, complexity heightens. Inventory management allows visibility to applications and APIs, which facilitates an understanding of the possible pitfalls and blind spots needing attention.
An application may contain an API endpoint used for testing but forgotten and not removed during publishing. An attacker can access the endpoint to gain sensitive data with the application owner unaware of the situation.
WAAS protects users against this risk by continuously scanning the environment and alerting on hidden web applications and APIs. At the same time, the API Discovery feature automatically learns the APIs endpoints structure and possible risk, giving users an understanding of their risk.
Unsafe Consumption of APIs refers to the security risks that can occur when API clients incorrectly consume APIs. This can include plaintext interactions between APIs and improperly validating data received from the APIs prior to processing.
Additionally, blind trust of third parties could go wrong. If a provider gets compromised, for example, an attacker could add malicious functionality to the service without consumers' knowledge. This can lead to exposure of sensitive data, unauthorized access and even execution of arbitrary code.
By prioritizing and addressing security risks, organizations can continue their growth and allow complex architectures to communicate via API while ensuring a secure and reliable digital ecosystem for all stakeholders.
Prisma Cloud is the first cloud-native application protection platform (CNAPP) to provide an integrated approach to Web Application and Api Security (WAAS). WAAS is designed to stop attacks against the OWASP Top 10 and protect APIs while delivering cloud workload protection, cloud security posture management, vulnerability management, code security and application security.
If you’ve haven’t experienced Prisma Cloud, we invite you to take it for a test drive in a free 30-day Prisma Cloud trial.