After more than 20 years in the making, now it’s official: APIs are everywhere. In a 2021 survey, 73% of enterprises reported that they already publish more than 50 APIs, and this number is constantly growing.
APIs have crucial roles to play in virtually every industry today, and their importance is increasing steadily, as they move to the forefront of business strategies. This comes as no surprise: APIs seamlessly connect disparate apps and devices, bringing business synergies and efficiencies never witnessed before.
However, APIs have vulnerabilities just like any other component of the software. Adding to that, if they aren’t rigorously tested from a security standpoint, they can also introduce a whole new array of attack surfaces and expose you to unprecedented risks. If you wait until production to discover API vulnerabilities, you can incur substantial delays.
APIs are attractive to attackers, not just businesses
Keep in mind that APIs do more than simply connect your applications; they change the functionality in unpredictable ways. Many of the unique weaknesses that APIs may introduce are well known to hackers, who have developed different methods to attack your APIs in order to access the underlying data and functionality.
According to the OWASP API Top 10, it is not uncommon for legitimate, authenticated users to exploit the API by utilizing calls that appear legitimate but are actually intended to manipulate the API. These kinds of attacks, aiming to manipulate the business logic and exploit design flaws, are attractive to attackers.
You see, every API is unique and proprietary. As such, its software bugs and vulnerabilities are unique and “unknown” as well. The type of bugs that lead to attacks at the business logic or business process level is particularly challenging to identify as a defender.
Are you giving API security testing enough attention?
Shift-left security is already widely accepted in many organizations, allowing for continuous testing throughout development. API security testing, however, often falls through the cracks or is performed without a sufficient understanding of the risks involved. Why is that? Well, there is more than one reason:
- Existing application security testing tools are generic and aim at traditional web app vulnerabilities, and can’t effectively handle the business logic intricacies of an API.
- Because APIs don’t have a UI, it is common for companies to test web, app, and mobile separately – but not the API itself.
- Testing APIs can be manually intensive and is not scalable when you have hundreds of them.
- Relevant experience and expertise may be in short supply, as API testing is more complicated than other types of testing
- With legacy APIs, you might not know about the APIs already implemented or the documentation.
So, while shift-left security is already valued by many organizations in general, API security testing is too often left out of the DevSecOps big picture.
This is unfortunate, since API vulnerabilities require longer to remediate than traditional application vulnerabilities – in a recent survey, 63% of respondents reported that it takes longer to remediate API vulnerabilities. This number is also likely to rise given applications’ rapid adoption of and dependence on APIs.
While most security leaders are aware of the importance of API security testing, just under half say they don’t yet have an API security testing solution fully integrated into their development pipeline.
Why do common security testing approaches fail to cover APIs?
As a first step towards a comprehensive approach, it is important to examine the most common attitudes towards application security testing today: static security testing and dynamic security testing.
Static security testing takes a white-box approach, creating tests based on the known functionality of the application by reviewing the design, architecture, or code, including the many complex paths that data can take as it passes through the application.
Dynamic security testing takes a black-box approach, creating tests based on the expected performance of the application given a particular set of inputs, disregarding internal processing or knowledge of the underlying code.
When it comes to APIs, developers and security teams frequently argue over which of the two methods is most appropriate, with the leading reasoning in favor of each being:
- Static testing is the only method that makes sense: since there is no user interface for APIs, you have to know what’s going on inside the business logic.
- Dynamic testing is all that is needed, since unit tests use static models and have already been completed at an earlier stage of the pipeline.
Sorry to ruin the party, but both of these points are only partially true. As a matter of fact, both approaches are necessary to ensure broad coverage and handle a variety of possible scenarios. Especially with the current rise of API-based attacks, you cannot take any chances when it comes to scalability, depth, and frequency.
‘Grey-box’ API security testing may offer an interesting alternative. Since there’s no user interface, having knowledge of the app’s internal workings (e.g., parameters, return types) can help you efficiently create functional tests that focus on the business logic.
Ideally, combining aspects of API security testing would get you closer to creating a grey-box solution that compensates for the weaknesses of each of these individual approaches. Such a business logic approach would intelligently examine results of other test types and can adapt to apply improved tests, either automatically or manually.
It’s time for a Business Logic API Security Testing Approach
There’s growing industry awareness surrounding the need to secure APIs across their lifecycle, placing APIs front and center in your security controls.
To do this, you must find ways to simplify and streamline your organization’s API security testing, integrating and enforcing API security testing standards within the development cycle. This way, along with runtime monitoring, the security team can gain visibility into all known vulnerabilities in one place. As a bonus, taking steps to shift-left API security testing will cut costs and accelerate time to remediation.
Moreover, once your testing workflows are automated, you’ll also have built-in support for retesting: a cycle of test, remediate, retest, and deploy, keeping your pipeline running smoothly and avoiding bottlenecks altogether.
A business logic approach to API security testing can elevate the maturity of your Full Lifecycle API Security program, and improve your security posture.
However, this modern approach requires a tool that can learn as it goes, improving its performance over time by ingesting runtime data to gain insights into the application’s structure and logic.
This would involve creating an adaptive test engine that can learn as it goes, developing a deeper knowledge of the API’s behavior in order to reverse-engineer its hidden inner workings intelligently. Using runtime data and business logic information, you can enjoy the best of both worlds – the black and white box approach towards enhanced visibility and control with automation.
To wrap up
In addition to their increasing popularity, APIs also create greater vulnerability for web applications. A large number of organizations do not even know what the extent of their APIs and vulnerabilities are. Known and unknown weaknesses can easily be probed by hackers via available APIs.
However, API security testing is often overlooked and handled the same as web applications. Most testing approaches, such as black-box and white-box testing, are not conducive to API testing.
A combination of natural language processing and artificial intelligence (AI) offers a viable “grey box” option that automates, scales, and simplifies the complex process of API security testing.