Mitigating OWASP API Security Top 10 Risks with Ping Identity

Given the critical role they play in digital transformation—and the access to internal data and systems they provide—APIs warrant a dedicated approach to security and compliance. Already an attractive target for bad actors, APIs will soon become a top attack vector. As part of its API security report released in August, Gartner recommended adopting “a continuous approach to API security across the API development and delivery cycle, designing security into APIs.” 

To effectively combat API security risks, however, a common understanding of the specific threats that enterprises need to defend against is essential. To this end, the OWASP Foundation created the OWASP API Security Top 10 project. In this post, I look into some of the risks described by OWASP API Security Top 10 and how the relevant Ping Identity products can be leveraged to mitigate these risks.

Since the early days of web APIs, API developers and security practitioners have leveraged Ping Identity’s thought leadership and tools. After all, authentication and authorization for API transactions starts with OAuth, and Ping Identity has been a contributor to the OAuth standard for nearly a decade and was an early implementer of the OAuth authorization server. Since then, and to this day, Ping Identity team members have also been involved in the definition of JWT, token revocation, token introspection, dynamic client registration, financial-grade APIs, and myriad other relevant specifications that guide API practitioners in securing their APIs. 

Beyond this rich involvement in issuing and handling API tokens, Ping has recently innovated in the API security domain with three products: PingAuthorize, PingIntelligence for APIs and PingAccess. Let’s take a look at the benefits these products provide from OWASP API Security Top 10’s perspective.

The most common API style today is REST, in which objects are represented as resources and uniquely identified through HTTP URIs. Broken object level authorization occurs when an API fails to apply access control rules based on the object (the resource) being accessed or acted upon. It’s no mistake that this risk makes the top of the list, as many API breaches occur as a result of a lack of authorization check.

PingAccess has several OAuth policies that are available for use out of the box. These include basic policies, such as validating the scope used in the token or attributes included in the token. In addition, the entire transaction set (for both the request and the response) is available for another rule-type that uses Groovy Script for much more flexibility. These rules, in conjunction with standard access control rules such as time ranges or network address ranges, can be used to create a defense-in-depth strategy.

Broken authentication can be either an API or part of an API that can be accessed without any authentication checks or a vulnerable authentication mechanism such as an authorization server that does not have any protection against credentials stuffing or brute force attacks. Password recovery endpoints subject to brute force attacks also fall under this category.

PingFederate has a built-in password spraying prevention capability and a customizable password recovery self-service, and CAPTCHA can be configured on the authorization server. In addition, by utilizing PingID, you can implement multi-factor authentication (MFA) and the latest biometric and passwordless authentication mechanisms to limit any exposure from password spraying. Leveraging these authorization server best practices and assigning OAuth Scope and/or OAuth Attribute policies to all API resources using PingAccess is a great way to protect your API against this risk.

API clients (such as mobile apps and websites) tend to hide data returned by an API and only show what is needed for the scope of UI element(s) being displayed. If a privacy-focused security tester uses the client-side application (as end-users do) to check that no personally identifiable information (PII) is leaking through the app, for example, they may not get the full picture because the API behind the scene would include data not displayed in the app. This can be a severe security blind spot! Hackers can skip client-side applications and have access to all the data being returned by APIs.

PingDataGovernance inspects structured data flowing out of your APIs and applies policies against this data. In addition to static rules, PingDataGovernance consults latest end-user consent records or privacy preferences, and can redact API responses on the fly so that you can apply new fine-grained authorization rules without the need to change back-end API endpoints. In addition to this, PingIntelligence for APIs models data returned by your APIs for various clients and end users over time. If a hacker finds a way to perform a data exfiltration attack on your API, this will deviate from the model and trigger an anomaly, which will result in the offending API client being blocked.

API endpoints consume server-side CPU, memory and other limited resources. An attacker of your API may attempt to overwhelm your API and disrupt your service by using excessive resources. Such denial of service attacks may be achieved not only through executing an excessive amount of API requests but also by manipulating input parameter values in a way that increases the resources used by each request.

PingAccess implements rate limiting rules, which lets you specify max bust and request intervals as well as granularity policies on a per-identity, per-IP and per-OAuth client basis. PingIntelligence for APIs also monitors request rates and API back-end response times per API client and looks for deviations from a model automatically learned by inspecting historical API traffic.

This risk occurs when an API fails to fully authorize API calls by not taking into consideration the role of the requester, the HTTP verb, the full URL and the input parameters. As its name suggests, this risk is similar to API1 Broken Object Level Authorization but differs in that it applies to executing a function rather than accessing a resource. As such, the rules that can be defined and enforced by PingAccess protect against this type of risk. Because PUT and POSTS API calls also let you define input parameters in the payload itself, the use of PingDataGovernance to inspect incoming structured data in payloads can further be of assistance.

OWASP goes on to describe five more API security risks, ranging from improperly configured infrastructure to missing input validation and insufficient monitoring. In the end, security is everybody’s job. Software developers should always apply input sanitization at the code level, and API gateway operators should ensure that incoming structured data be validated against schemas. Also, you may invest tremendous effort in controlling access at the API level, but if your backend is left wide open or your gateway is bypassed in some way, you will be vulnerable to attacks. Looking at recent breaches, we realize that attacks go unnoticed for months or even years. This clearly points to a lack of monitoring.

Because human error can never be fully eliminated and because attackers may abuse your APIs in novel ways that you may not consider as you define your security requirements, it’s important to apply a defense-in-depth approach. Multiple layers of security minimize your overall risk. This is why PingIntelligence for APIs focuses on detecting anomalies in your API traffic. Having visibility into these anomalies ensures that attacks will not go unnoticed for long. Looking for these anomalies also minimizes the damage caused by human error when you fail to maximize the potential of your foundational API security infrastructure.

To learn more about how you can protect your APIs against the latest threats by using PingAccess, PingDataGovernance and PingIntelligence for APIs, along with the rest of the Ping Intelligent Identity platform, I invite you to download this white paper today.