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
Recommended by LinkedIn
It is not because your security partner sponsors the OWASP foundation that they also address all the risks in their product.
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.