OWASP TOP 10: APIs Take Center Stage in Latest List of Priorities

OWASP recently released the first iteration of the API Security Top 10. Like the ubiquitous OWASP Top 10, the API Security Top 10 delivers a prioritized list of the most critical application security issues with a focus on the API side of applications. This is a critical new tool for AppSec teams that hones in on one of the fastest growing, yet chronically under-addressed aspects of security. In this blog, I’d like to offer you an overview of the API top 10 with comparisons to the OWASP top 10 for web applications.

APIs are on the Frontlines of AppSec

APIs have fundamentally changed how applications are architected and how information flows to and from end-users. While they have made development faster and applications more dynamic, they also present new security challenges and introduce new potential avenues for attack. Applications often rely on a variety of APIs and they can expose functions that wouldn’t necessarily be visible in a traditional web application. Additionally, much of this new attack surface may be invisible to a legacy WAF, which often only sees traffic in and out of the application.

APIs have many of the same weaknesses found in traditional applications, while also introducing some entirely new issues that must be addressed from scratch. Unfortunately, legacy WAFs typically don’t address the unique challenges of APIs, and API gateways lack the ability to detect and stop threats. This ultimately results in an application attack surface that is broad, easily accessed, and poorly defended by legacy security tools. As a result, it is no surprise that Gartner predicts that by 2022, APIs will be the most frequent attack vector leading to breaches for web applications.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Enter the API Security Top 10

With the growing importance of APIs, it makes sense that this area starts to get equal consideration when it comes to AppSec, and the API Security Top 10 is a great step in that direction.

Upon first examination, it is clear that the API Top 10 shares a lot in common with the traditional Top 10. In fact, 6 out of the 10 categories in the API Top 10 are also in the traditional Top 10 or have a very close analog. This should come as no great surprise. APIs provide new avenues to modern applications, but many of the same challenges and weaknesses remain. APIs, after all, are an extension of applications, not a complete reimagining. The table below provides a side-by-side comparison and highlights the areas in the API Top 10 that are also found in the 2017 OWASP Top 10.

AppSec teams should not be lured into a false sense of security because of these similarities. APIs can introduce new twists and challenges that organizations need to account for even with traditional, well-known risks. For example, both lists contain ‘Injection’ in their Top 10 (#1 in the OWASP Top 10, and #8 in the API Top 10). Yet, while many organizations may detect and block injection attacks against their traditional web front-ends, that protection often doesn’t translate to their APIs.

Legacy security tools like a WAF may not be in a position to see an attack via an API. APIs allow a multitude of new paths to the backend of an application, and in many cases, these connections could even be east-west connections between modules and microservices that a traditional monolithic WAF would not see. Additionally, attacks can be obscured within additional API-specific protocols such as JSON and WebSockets. Without the right visibility of traffic and the native ability to decode the relevant protocols, organizations could easily miss threats to their APIs that they would easily detect on a more traditional web app.

With this in mind, let’s briefly look at the categories where the OWASP Top 10 and and API Top 10 are similar, and then where the API Top 10 introduces new concepts.

Similarities Between the API Top 10 and OWASP Top 10

API2: Broken User Authentication
API2: Broken User Authentication is directly comparable to A2: Broken Authentication. They both address issues such as the susceptibility of the application to Brute Force and credential stuffing attacks, weak passwords, and the exposure or weak management of session IDs. Hower the API2 also calls out the very broad challenge of monitoring all of the many flows for authenticating to the API including “mobile/web/deep links that implement one-click authentication/etc.” Additionally, teams need to be aware of properly securing JSON Web Tokens (JWT) and proper authentication hygiene such as not using API keys for authentication.

API3: Excessive Data Exposure
At a high level, API3 is related to A3: Sensitive Data Exposure. However, they do have a very different set of issues. The traditional OWASP A3 takes a rather holistic approach to the encryption and retention of data, ensuring data is encrypted at rest and in transit and secured while in use. The API3 conversely focuses heavily on the issue that APIs often rely on the client to filter data in API responses. This could allow an attacker to easily sniff API response traffic to see sensitive data. This vulnerability requires that developers take the added time to specifically pick and choose the data that needs to be returned from the API rather than simply relying on the client to filter sensitive data.

API5: Broken Function Level Authorization
API5 is very similar to A5: Broken Access Control. Both controls call out the risks where a user could access functions that they should not have access to through simple modifications of URL, such as changing a GET method to a PUT, or guessing URL parameters for sensitive functions. Notably, the traditional OWASP category A5, provides a great deal of focus on APIs for this particular control.

API7: Security Misconfiguration
API7 maps directly to A6: Security Misconfiguration. Both controls focus on the identification of unpatched flaws, exposed accounts, assets, and other information that could lead to unauthorized access or knowledge of the application. The API Top 10 further calls out important scenarios such as where “an attacker finds the .bash_history file under the root directory of the server, which contains commands used by the DevOps team to access the API…” An attacker could also find new endpoints on the API that are used only by the DevOps team and are not documented. Organizations should be sure to:

API8: Injection
As discussed earlier, API8 maps directly to A1 of the OWASP Top 10. In addition to the need to validate input for a variety of malicious inputs, security teams will need to account for additional challenges of APIs. This includes the ability to sanitize all inputs– even from internal sources such as internal modules or services. Teams may also want to consider using an API that provides a parameterized interface.

API10: Insufficient Logging and Monitoring
Both the API Top 10 and OWASP Top 10 end with ‘Insufficient Logging and Monitoring’. These issues highlight an all too common problem that allows threats to go unnoticed for extended periods of time simply because organizations lack the alerting and visibility into security events in their applications. While this is a common issue in traditional web applications, it is greatly exacerbated in APIs which often receive far less threat-based monitoring and alerting as compared to the web frontend.

“review and update configurations across the entire API stack…including orchestration files, API components, and cloud services (e.g., S3 bucket permissions)… secure communication channel for all API interactions access to static assets (e.g., images)…and an automated process to continuously assess the effectiveness of the configuration and settings in all environments.”

New Categories in the API Top 10

API1: Broken Object Level Authorization
One of the most significant differences in the API Top 10 is the importance placed on object-level authorization. This is an incredibly common problem in APIs. As the API Top 10 states, “APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue.” This can lead to problems when user-based access controls discussed previously (API2) are not checked and enforced at the object level. Additionally, developers should ensure they use “random and unpredictable values as GUIDs for records’ IDs” to prevent attackers from easily manipulating or guessing commands.

API4: Lack of Resources & Rate Limiting
It is important for security teams to understand how users are consuming resources in order to avoid denial-of-service attacks. And while rate limiting is discussed in other sections of the OWASP Top 10, it gets called out specifically in the API Top 10 due to the frequency of attack in the wild. In addition to tracking standard aspects of an application such as the number of overall requests, security teams also need to track resource-intensive requests that could consume large amounts of memory or compute on the application.

API6: Mass Assignment
Applications and their APIs often need users to update information such as their contact information or other personal data. However, problems can occur if the application extends this capability to other internal properties such as a state flag or other setting that should only be set by an administrator or the application itself. For example, an attacker might find that in addition to updating the user’s mailing address, he can also update the amount of funds in his account, allowing him to effectively steal from the application. As a result, applications should “avoid using functions that automatically bind a client’s input into code variables or internal objects” and use whitelists and blacklists to further control user access to specific variables.

API9: Improper Assets Management
This issue relates to the prevalence of old or unpatched APIs that can accumulate in an application unnecessarily. These may be APIs that were used in the development and testing process or for older versions of the application, but were never properly removed or retired. These APIs are often vulnerable or poorly secured and can allow an attacker to easily abuse the application without the need for a more sophisticated exploit. This issue underscores the importance of enumerating all API hosts in an environment, understanding their purpose, age, and susceptibility to attack. Likewise, organizations should be able to apply monitoring and protection against all API hosts to protect them from abuse.

Conclusion

Here we have briefly introduced some of the high points of the OWASP API Top 10 and how it both aligns with and differs from the OWASP Top 10. While this introduction provides a basic roadmap for some of the more common API-related security issues, there remains a wealth of additional details and considerations when teams need to implement a robust API-ready security program. ThreatX provides a very unique approach to application security that provides effective security both to traditional web applications and APIs. Additionally, the ThreatX platform detects both known and unknown attacks using a combination of behavioral analysis, active attacker engagement, deception and more. This allows organizations to secure their applications in any state (traditional web frontend, API, local, cloud, etc) from a full spectrum of threats (traditional attacks, bots, targeted attacks, DDoS and more).

If you would like to learn more about specific ways that ThreatX can address the security of your apps and APIs, please contact the ThreatX team at [email protected].