Dr Doron Chema, L7 Defense Cofounder and CEO discusses the origins and current trends in API security.
API vs. Application: Genesis or starting from scratch?
At the beginning, there were web applications. Each web application is made of a collection of web pages, static, dynamic, and everything in between.
Fast forward, the first app was born.
Apps are also made of web functionality. However, app functionality twisted the good old web page backend functionality into Application Programming Interfaces (API). API is a well-defined functional web unit made to perform a single task. For instance, an API that manages the “User Login”.
Just like in classical biological evolution, as nature recognizes a working, “efficient”* concept (*where efficient means that it can be re-used “as is” multiple times), it tends to duplicate it in a mass. So, APIs became the “official” internet industry building blocks and new creative forms of consuming them are born occasionally. Recent research reveals that organizations manage hundreds of APIs, most ‘born’ less than 30 days ago. Moreover, the growth of the API economy is an essential step toward a fourth industrial revolution, being called ‘the rise of the autonomous economy’, which relies on mass automation enabled by the fast-growing usage of AI machines.
API vs. Application Security: “Two roads diverged in a yellow wood”
Zooming in to the impact of APIs on our economy, it is clear that no good comes without drawbacks; in our case, let’s focus on the cyber-security risk.
In order to do so, we will compare the challenge of protecting APIs versus the challenge of protecting applications. The first thing that comes to mind with the API is: application relationships. Each API may serve multiple applications, while the reverse isn’t true. So, the relation is usually, one-to-many with branches in between. This leads to three major observations on the differences between APIs and application security.
-
- First, each API faces a wide range of attacks that may come from a wide applicative surface. Attacks may come from multiple applications (internal, external, supply chain) and different kind of end users (B2C, B2B). For “normal” web functionality, all attack types already known for Applications are also relevant for APIs. The Open Web Application Security Project (OWASP) recognized API security as a primary concern, with 9 of the top 10 vulnerabilities in their current OWASP Top 10 report including an API component. Application security protects against a specific application range, and is usually tuned to follow the normal usage of the application and find exceptions from this trend, a heavy task in itself, sometimes claimed to be almost impossible.
- Second observation is that the API attack may become as a sort of a chain reaction! Damaging a single API will most probably cause damages to multiple applications, in turn, with the potential for causing even more damage by a secondary reaction to other APIs as well, and so on. For application security, this is rarely the situation. Spread of the damage to other applications is not expected, rather damage is usually kept local to the damaged application and closely related apps, if any.
- Third, observation refers to the sensitivity of defense layer while neglecting requests during attack mitigation. API functionality is usually sensitive. No customer should be lost by mistake. Therefore, the accuracy of the defense layer should be for the max, for each API as a standalone. Now, one should remember that each API has a different profile of usage, which take this problem far away from the ability to tune its profile manually as still is made for Application Security. The outcome from these observations is that API security is significantly diverting from the traditional application security and should be led by high resolution approach, automation and high accuracy while protecting on each and every API as a standalone, within the framework of thousands of these working together.
