Abstract: This white paper examines the OWASP API Security Top 10 list providing analysis and recommendations for enterprises, including how a context-aware security model can protect you against these vulnerabilities.
About the OWASP and the Top 10 Web Application Security Risks
Open Web Application Security Project (OWASP) is a non-profit, collaborative organization that publishes awareness documents for developers and web application security. It is well known for the Top 10 Web Application Security Risks, first published in 2003 and last updated in 2017. This list represents a broad consensus about the most critical security risks to web applications.i
A separate top 10 security list for APIs is needed
In 2019, OWASP decided to release the first edition of an Application Program Interface (API) security vulnerabilities list as companion to the widely referenced Web Application Security Top 10. Although APIs are technically a component of a web application, they have grown enough in importance to warrant their own list.
OWASP’s research has followed the exponential increase of API use in application development. APIs are now one of the most important tools in rapid application modernization and integration today. Open banking has mandated that banks open their APIs to FinTechs. APIs now provide the backend for countless websites, mobile apps, and IoT applications, and so API endpoints have become the gatekeepers of the world’s data.ii Many API endpoints equals many vulnerabilities and increased risk for API data breaches. There arenearly daily breaches, often caused by the core concerns of the OWASP top 10.
According to Gartner, APIs will account for 90% of the attack surface by next year, and by 2022, APIs will become the most frequent attack vector.iii
The OWASP API Security Top 10 and Cloudentity’s recommendations
As we review the Top 10 vulnerabilities, we arrive at the following conclusions:
- All the vulnerabilities are directly or indirectly related to authentication or authorization
- APIs need to be given unique identities with their own policies, authentication, and authorization processes separate from the web applications that call them
In the following sections, we analyze the OWASP API Security Top 10with a context-aware Five W authentication and authorization lens.
API 1 – Broken Object Level Authorization
“APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.”iv OWASP
Recommendation
Authorization policies must explicitly identify every object by its individual data attributes to define the scope of data that is allowed or denied on an API-by-API basis.
Attackers can exploit API endpoints vulnerable to broken object level authorization by manipulating the ID of an object sent within the client request. This means the client can request information from an API endpoint that they are not supposed to have access to. This attack normally leads to unauthorized information disclosure, modification, or destruction of data.4
API 2 – Broken Authentication
“Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify the client/user, compromises API security overall.”v OWASP
Recommendation
Use single-use authentication tokens at the transaction level for each API and not at the session level. Single-use authentication tokens are a highly effective authentication method. Deploying them at the API level reduces the risk of latency.
Unlike authorization, authentication is a complex and confusing mechanism for APIs. Since authentication endpoints are exposed to anyone by design, the endpoints responsible for user-authentication must be treated differently from regular API endpoints and implement extra layers of protection forcredential stuffingattempts, in addition to brute force password and token guessing attacks.vi
API 3 – Excessive Data Exposure
“Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.”vii OWASP
Recommendation
Implement the recommendations of API 1 (above) and apply the resulting fine-grain authorization to every inbound and outbound request made to the API.
API endpoints often expose sensitive data by design since they frequently rely on the client app to perform data filtering. Attackers exploit this weakness by sniffing the traffic to analyze the responses, looking for sensitive data that should not be exposed.viii
API 4 – Lack of Resources & Rate Limiting
“Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.ix OWASP
Recommendation
Implement API security policies that limit the number of requests and the types of requests that consume large amounts of resources. Provide load balancing and spike arrests at the Edge to protect backend services and prevent DoS. Ensure that your security processes and technology will scale as your scalable systems grow.
It is common to find API endpoints that do not implement any sort of rate limiting on the number of API requests, or they do not limit the type of requests that can consume considerable network, CPU, memory, and storage resources. The resources required to satisfy a request greatly depends on the user input and endpoint business logic. Attackers exploit these issues, causing denial-of-service attacks and associated endpoint outages.x
API 5 – Broken Function Level Authorization
“Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.”xi OWASP
Recommendation
Use a cybersecurity approach that allows you to simplify and standardize security policies that apply context-aware identity authentication and authorization enforcement to each individual API.
Overly complex control policies that do not separate administrative and regular functions are targets for hackers because they can hide exploitable access loopholes. Administrative functions are prime targets for this type of attack. Exploitation of this issue requires the attacker to send API requests to endpoints that they should not have access to, yet are exposed to anonymous users or regular, non-privileged users.xii
API 6 – Mass Assignment
“Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.”xiiiOWASP
Recommendation
Avoid using only application edge enforcement techniques as they only allow or deny all flows, creating substantial vulnerabilities. Define and deploy security policies which apply context-aware identity authentication and authorization enforcement to each individual API.
Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Attackers can use this methodology to update or overwrite sensitive object’s properties that the developers never intended to expose.
Exploitation usually requires an understanding of the business logic, object relations, and API structure. Exploitation of mass assignment is easier in APIs, since by design they expose the underlying implementation of the application along with the properties’ names.xiv
API 7 – Security Misconfiguration
“Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.”xv OWASP
Recommendation
Separate code and security policies with an externalized authorization model and add consistent security policies to the entire Continuous Integration/Continuous Development pipeline to avoid last-minute changes and misconfigurations.
Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system.xvi
API 8 – Injection
“Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.”xvii OWASP
Recommendation
Define and deploy security policies that apply context-aware identity authentication and authorization enforcement to each individual API.
Injection vulnerabilities are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. They cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally lead to data theft, data loss, data corruption, denial of service, etc.xviii
API 9 – Improper asset management
“APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.”xix OWASP
Recommendation
Practice good asset management hygiene. Create a detailed inventory and know the lineage for every API. In addition, define and deploy security policies that apply context-aware identity authentication and authorization enforcement to each individual API.
Old API versions are often unpatched and can become an easy way to compromise systems without having to fight state-of-the-art security systems, which might be in place to protect the most recent API versions. Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database.
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and inventory of deployed API versions also play an important role in mitigating issues such as deprecated API versions and exposed debug endpoints.xx
API 10 – Insufficient Logging and Monitoring
“Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.”xxi OWASP
Recommendation
Implement a Zero Trust architecture with logging and monitoring that tracks and evaluates all north/south and east/west network traffic. Deploy dynamic authorization that is context-aware, that allows you to define, at the API level, the “who, what, where, when and why” scenarios that govern whether requests are accepted or denied.
Cloudentity can protect you against the OWASP API Security Top 10
Cloudentity’s Zero Trust dynamic authorization platform provides the strongest context-aware identity and enforcement for every API endpoint that you have.
Cloudentity’s platform takes a unique approach to bundling modern IAM and API best practices into lightweight application layers to support CI/CD and DevOps for rapid and safe application modernization. Our Cloudentity MicroPerimeter™ with CIAM will help you implement MFA, OAuth 2.0, and OIDC to deploy robust identity and enforcement across your enterprise. You can access a free trial or software demo here to experience how this might work for you.
See you on the secure side.