4 Assumptions Preventing Effective API Protection

This post is also available in: French German Italian Portuguese (Brazil) Spanish

It’s no secret to anyone that every modern application is making use of APIs to interact with its different components, its users and sometimes with external services. In fact, API usage surged during 2021. According to market research, API attack traffic has tripled in growth compared to the overall API traffic. On top of that, Gartner estimated that in 2021, over 50% of all data theft incidents were traceable to unsecured APIs.  

So why hasn’t API protection kept up with API usage? Based on what we are hearing from companies about their API protection strategies, it seems many are making a few false assumptions that are leaving their APIs vulnerable and exposed to threats.  
 
Assumption #1: My WAF protects my applications and their APIs 

While this assumption is correct to a certain extent, APIs are exposed to many threat vectors that most web application firewalls (WAF) can’t protect.  

To begin with, most WAF solutions were designed to protect web application vulnerabilities. APIs, on the other hand, require specific analysis, like the ability to parse their content and compare it against the API’s specific schema. Standard WAFs usually do not include these types of capabilities. 

Secondly, most WAF solutions (especially cloud WAF managed services) only deploy negative security models. This limits the solutions from providing protection against zero-day attacks, which are unfamiliar attacks for which no signature yet exists. The OWASP API top ten threat vector list includes many types of attacks that simply can’t be covered through a negative security model. They require a positive security model and behavioral analysis to identify whether the API call is malicious or not — a feature most WAFs simply don’t have. 

Finally, there are also automated threats, including malicious bots, that can pose a big problem for APIs. How can you distinguish between a bad bot and a legitimate machine-to-machine call? Advanced bot management solutions, which can also analyze API calls, are required to protect against bad bot attacks, such as account take over (ATO), data scraping and other types of application Dos attacks. Currently, no WAF offers this functionality. 

[You may also like: Five Common Pitfalls in Application Protection]

Assumption #2: My API Gateway manages and protects my APIs 

API gateways were always designed to manage the lifecycle of APIs, translate protocols, route API calls to the correct destination, and manage quotas to ensure the server resources handling the API calls are not exhausted or abused. 

In addition, API gateways authenticate the entity that makes the API call to ensure that the entity has the authorization to execute each specific call. Some API gateways also have an integrated signature-based engine to provide additional protection to the API calls they process. While these are all important functions, they are not enough to provide effective API protection. There is no API gateway solution to date that includes API protection with a positive security model engine, bot protection capabilities, behavioral analysis, and application DoS protection. 

Did you know that all API calls are centralized to pass through API gateways? This only holds true for known and managed APIs. Consequently, in many organizations, there are many undocumented and unmanaged APIs which go unaddressed – and it’s impossible to protect what you don’t know exists. 

Moreover, most API gateways include hooks for integration with third-party API protection solutions. This is a clear statement from API vendors, understanding their API gateway’s limitation in protecting the very APIs they manage. 

Assumption #3: My APIs are well documented, enabling effective protection 

Indeed, to effectively protect an API, you need to intimately know the API structure, its possible parameters, the type and range of values, and the expected content of the API body. Well-documented APIs, combined with a good API protection solution, can dramatically increase protection. 

However, in most cases, not all APIs used in an organization are documented. And even if they are, APIs change more frequently than applications. As a result, their documentation and the security policy need to be updated on a regular basis; a task that doesn’t happen as regularly as it should. And if you ask security architects, most will tell you they don’t trust the API documentation. 

Any effective API protection solution must include automatic discovery of APIs. This includes discovering not only their existence but also their structure (i.e., schema), their parameters, type of parameters, and their value ranges. A good discovery engine can also automatically generate and apply a tailored security policy to match the discovered APIs to effectively protect them. This is the best way to effectively protect an API throughout its lifecycle. 

[You may also like: How To Achieve Application Protection Behind AWS/Azure CDN]

Assumption #4: I have a dedicated API Protection solution – I am covered 

Having good API protection that covers the recommendations mentioned in this blog is a great start. But it is just that — a start — and not enough to fully protect your application. APIs don’t exist by themselves. They are part of an application. The application is deployed on an infrastructure. Hackers who can’t find their way in through the APIs will look for a way in through an application vulnerability that is unrelated to the API. They might launch a bot attack or simply attack the infrastructure with a DDoS attack. 

Application protection should be viewed in a holistic way — that means all bases must be covered. Your protection is only as strong as its weakest link.  
 
API protection is only one important component in your overall application protection architecture, which should also include a strong WAF, bot management, threat intelligence and DDoS protection. If you can manage these solutions from a single pane of glass and synchronize them, your applications and APIs will be effectively protected. 

Want to learn more? Please join our webinar, where we will provide more information on best practices to tackle the protection gaps presented in this blog.  

Like this post? Subscribe now to get the latest Radware content in your inbox
weekly plus exclusive access to Radware’s Premium Content.