How-to Protect Your APIs from OWASP API Security Top Ten – (part one)
In a recent blog series, my colleague, Bill Oakes, discussed the OWASP Top Ten web-based threats and how a proven API management solution can help mitigate against those threats. So, that covers web applications, but what about APIs? Several analysts are pinpointing APIs as one of the top attack vectors over the next four to five years. OWASP has seen this, and has another project outlining the ten most critical security concerns for API security, known as the OWASP API Security Top Ten. This two-part blog will take a look at each of these, and how enterprises can use API management to prevent these threats.
API management has long helped customers simplify and accelerate the security, integration and management of their web services and web API traffic. Many enterprises are looking to extend that same functionality to API security from endpoint to the backend. Depending on your requirements, an API management solution can be your one security gateway for all APIs under the API management solutions umbrella.
Let’s take a look at the first five of the OWASP API Security Top Ten concerns. I’ll describe each of these common vulnerabilities as defined by The OWASP API Security Top Ten Project, and how to protect your enterprise from these vulnerabilities.
API1:2019 Broken Object Level Authorization
The order of the items in this list matters. It’s no surprise that Broken Object Level Authorization (BOLA for short) earns the gold medal: it’s a common bug and one of the first patterns used by hackers looking for vulnerabilities. Your API suffers from BOLA if a hacker can manipulate API requests to access, or act on, objects that they should not be able to. Your API may be authenticating each client request, but it may not be applying authorization rules that dictate which object can be accessed by which client. Authentication by itself is not sufficient, hackers are users too and they may have a valid account for your service.
Should object-level authorization really be in the scope of API security, or should it fall more under application security, or even under data security? This confusion may in fact be the root cause for this item making the top of the list. Preventing BOLA requires checking that authorization rules are in fact in place, and that there is no way that the API client may work around them, no matter how the API is requested. Implementing such authorization rules may happen ‘downstream’ from the API layer, in which case the API client identity needs to propagate into these downstream layers in order for these authorization rules to be validated properly. API gateways assist in propagating this identity context downstream in a format compatible with the downstream domain.
Since the API layer is often the main channel into an application, applying object level authorization in the API layer is helpful. Delegating some access control out of the backend application and into the API layer can yield more consistent security across APIs as well as enable authorization rule changes to adapt to new requirements at the speed of business. An API gateway can correlate identity claims, scopes and object level properties from structured payloads (e.g. JSON) or headers. External decision point can also be consulted by API gateway nodes.
API2:2019 Broken User Authentication
Broken authentication is one step lower down the stack. Your API suffers from this problem if there is a lack of authentication or there is a way to bypass the normal authentication. An example of this problem is when an API requires a JWT token with specific claims but stops short of validating the issuer of the tokens. As a result, a hacker generating their own JWT with their own key would be able to impersonate anyone on such an API. An API gateway should validate the authenticity of incoming tokens against a set of trusted token issuer certificates. The API gateway also plays a role during the token issuing process when an end-user identity is authenticated by coordinating with a specialized identity and access management infrastructure where multi-factor authentication is applied to reduce the risk of compromised credentials. Tight coordination between API management and Identity management is key here.
API3:2019 Excessive Data Exposure
Data showing up on an application is typically retrieved via API calls, but the data visible via a graphical user interface does not tell the full story of what is returned by the API. Rather client-side application developers select which information to render in the application, ignoring the rest. This can create a blind spot for application security experts which may not have access to or even awareness of the API. Hackers skip the client-side application and operate directly at the API layer in order to exploit APIs that reveal more information than they should. Avoiding this type of issues requires an API-level inspection of all data flowing in and out of the API.
API gateways can also help excessive data exposure by inspecting and redacting data in transit. This pattern is common for APIs that are consumed by different groups of requesters for different purposes. Sometimes an internal API is leveraged for a new purpose and exposed to a partner or other 3rd party. API gateways let you expose a subset of an API to these different parties and ensure that only the necessary data is made available to these requesters who should see less.
API4:2019 Lack of Resources & Rate Limiting
APIs are a great way to share your service with multiple partners and developers but without restrictions on the resources consumed by each API consumer, it only takes one bad actor to ruin the API experience for everyone else, or even take down your entire service. Rate limiting an API is achieved via API gateways which enforce rate limits that are typically defined in an API management layer. It is important to be able to apply different level of limits – per user, per organization, per API.
Abusing an API is not only manifested by unusually high number of requests, a clever hacker may form a request in such a way that will consume an unusual amount of resource on the receiving end. For example, payloads with unusual levels of nesting, query-all type requests, circular logic, etc. You cannot expect each API developer to identify each of these cases and again API gateways are ideally suited for inspecting incoming requests to identify (and reject) those known to be problematic.
Not all denial of services are intentional. API providers are also victims of friendly-fire incidents where an internal process malfunctions in such a way that it results in an API being overwhelmed. Setting rate limits, quotas and input sanitization at the API gateway level is important not just for public APIs but for internal ones as well.
API5:2019 Broken Function Level Authorization
Closing off the first 5 on this list is another common authorization bug that is very similar to BOLA (#1) but about authorizing across different functions rather than authorizing across different objects. Protecting against this type of vulnerability requires to define authorization rules for read vs write operations, rules for HTTP GET vs rules for HTTP POST, rules for /objects vs rules for /admin. You get the picture, but just like is the case for BOLA, where do these rules belong?
Again in this case, API gateways are your first line of defense, branching policies that take these different functions into consideration.
In my next blog, I’ll take a look at API Security Threats 6-10 (similar to the above).