API Security: Why a WAF and application gateways are the wrong tools

API Security: Why a WAF and application gateways are the wrong tools

Application Programming Interfaces (APIs) are here to stay. Why? Because it is so damn easy to exchange data between services. There's an exponential growth of APIs and the overall API design pattern is the default developer pattern for enterprises to build & release new services.

You might have seen over the last few weeks that several -sometimes very large- companies experienced a data breach via their APIs. Just search for "API breach" and you will find tons of examples. If companies such as LinkedIn, Instagram, Facebook, Experian, Uber... can be a victim to this type of security incident, then you understand why Gartner predicts that by 2022 API abuses will become the most frequent attack vector. More than ransomware, phishing, and others! In my opinion, 2022 is conservative, it's happening now! You can be sure that all the previously mentioned companies (and I am gonna assume you as well) have implemented a variety of security measures to help reduce risks associated with APIs. They/you'll have Web Application Firewalls, 'traditional' Firewalls, Application Gateways, Intrusion Detection Systems,... So why do companies still get breached via their APIs? The answer is simple: they are the wrong tool for the job! And even if you instructed your developers to embrace a DevSecOps model -or as some call it, Shift-Left model- it does not mean that you can ignore the right.

I took the liberty to list the must-have functional requirements when you want to get serious about securing your APIs. You will see that most of the established security vendors do not offer these must-haves in their stack. I encourage you to ask your security partner/vendor and challenge them! Here we go:

API Security Solution Functional Must-Haves

  • Discover all your APIs! Perhaps the most critical for security teams is to identify the unknown. When API Security is only implemented via eg. an API Gateway then you can be sure that a lot of your APIs are 'rogue'. Within our customer base, we always discover unmanaged APIs. It sometimes goes up to 40% of APIs that are not routed via a gateway and/or firewall.
  • Automatically discover the different data types APIs are consuming (PHI, PII, Payment,…). This helps security teams to quickly assess which APIs need the most security attention. Besides identifying data types, I also recommend you look for a solution that can take specific actions whenever a single or a group of APIs starts to send/receive specific data types. For example, trigger an alert in ServiceNow, Jira, Slack,... whenever a specific API exposes a social security number.
  • Generate an always up-to-date API catalog based upon the Open API Spec standard based upon the actual network packets.
  • Keep track of every API change (eg. New field added in the request body, different authentication method,...)
  • Create and constantly update a baseline based upon the API, User and Data behaviors by leveraging machine learning models in the back-end and ensure that the solution analyzes the context of an API to identify correlations within the API request/response. Only when your solution does this, they will be able to help you with API anomaly detection. A rule-based security solution simply cannot scale with the complexity of APIs and these do not understand the business logic of an API.
  • The OWASP foundation published a top-10 list of common API Security patterns which you can find here. You should ask your security vendors how they help you identify all these risks and how they discover and analyze OWASP risks. You will be surprised!!

It is not because your security partner sponsors the OWASP foundation that they also address all the risks in their product.


  • Because a lot of the API security risks can be tied back to the back-end code, do ensure that the solution can help you to put remediation plans in place. This can be done either via integrations with SIEM solutions or collaboration tools, but also by closing the loop via integrations with Firewalls, Application Gateways, LoadBalancers,...
  • Leverage advanced cloud and network functionalities to analyze API traffic without impacting the API data path nor add any latency or additional hops to the API call.

The API Security market is a young and highly dynamic market and therefore clients are often not aware of the risks. If your only security practice is to route all API traffic through a solution such as Kong, NGINX, Apigee,... and apply some security policies to the traffic, then you are not safe! Below you can find a quick demonstration of the #1 API attack pattern 'Broken Object Level Authorization in combination with a Kong API Gateway which will show you that data can be extracted/manipulated even when you have an authenticated API session.


To view or add a comment, sign in

More articles by Steven D.

Insights from the community

Others also viewed

Explore topics