After more than 20 years of creation, it’s now official: APIs are everywhere. In a 2021 survey, 73% of companies said they already publish more than 50 APIs, and that number keeps growing.
APIs have a crucial role to play in virtually every industry today, and their importance continues to increase as they come to the forefront of business strategies. Not surprisingly, APIs seamlessly connect disparate applications and devices, bringing unprecedented synergies and business efficiencies.
However, APIs have vulnerabilities like any other software component. Plus, if not rigorously tested from a security standpoint, they can also introduce a whole new range of attack surfaces and put you at unprecedented risk. If you wait until production to discover API vulnerabilities, you may experience substantial delays.
APIs are attractive to attackers, not just businesses
Keep in mind that APIs do more than just connect your applications; they change functionality in unpredictable ways. Most of the unique weaknesses APIs can 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 Top 10 OWASP APIs, it is not uncommon for legitimate, authenticated users to exploit the API using calls that appear legitimate but are in fact intended to manipulate the API. This kind of attacks, aimed at manipulating business logic and exploiting design flaws, are attractive to attackers.
You see, each API is unique and proprietary. As such, its software bugs and vulnerabilities are also unique and “unknown”. The type of bugs that lead to attacks at the business logic or business process level are particularly difficult to identify as an advocate.
Do you pay enough attention to API security testing?
Shift-left security is already widely accepted in many organizations, allowing continuous testing throughout development. However, API safety testing 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 target vulnerabilities in traditional web applications, and cannot effectively handle the complexities of API business logic.
- Since APIs don’t have a user interface, it’s common for companies to test web, app, and mobile separately, but not the API itself.
- Testing APIs can be manual intensive and are not scalable when you have hundreds of them.
- Relevant experience and expertise may be scarce, as API testing is more complicated than other types of testing
- With legacy APIs, you might not be familiar with already implemented APIs or documentation.
So while left-shifted security is already appreciated by many organizations in general, API security testing is too often overlooked as part of DevSecOps.
This is unfortunate, because API vulnerabilities take longer to patch than traditional application vulnerabilities. This number is also likely to increase given the rapid adoption of applications and reliance on APIs.
While most security managers are aware of the importance of API security testing, just under half say they do not yet have an API security testing solution fully integrated into their development pipeline.
Why don’t common security testing approaches cover APIs?
As a first step towards a holistic approach, it’s important to look at the most common attitudes towards application security testing today: static security testing and dynamic security testing.
Static safety test takes a white box approach, creating tests based on the known functionality of the application by examining the design, architecture, or code, including the many complex paths that data can take as it passes through the application.
Dynamic security tests takes a black box approach, creating tests based on the expected performance of the application given a particular set of inputs, regardless of 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 more appropriate, with the main reasoning in favor of each being:
- Static testing is the only method that makes sense: since there is no user interface for APIs, you need to know what is going on in the business logic.
- Dynamic testing is all that is needed, as unit testing uses static models and has already been done at an earlier stage of the pipeline.
Sorry to spoil the party, but those two points are only partially true. In fact, both approaches are necessary to ensure broad coverage and handle a variety of possible scenarios. Especially with the current increase in API-based attacks, you can’t take any risks with scalability, depth, and frequency.
Gray-box API security tests can offer an interesting alternative. Since there is no user interface, knowing the inner workings of the application (eg, parameters, return types) can help you effectively create functional tests that focus on business logic.
Ideally, combining aspects of API security testing would bring you one step closer to creating a gray box solution that compensates for the weaknesses of each of these individual approaches. Such a business logic approach would intelligently examine the results of other types of testing and can adapt to apply enhanced testing, either automatically or manually.
It’s time to take a business logic API security testing approach
The industry is increasingly aware of the need to secure APIs throughout their lifecycle, putting APIs at the forefront of your security controls.
To do this, you need to find ways to simplify and streamline your organization’s API security testing, by integrating and enforcing API security testing standards into the development cycle. This way, in addition to execution monitoring, the security team can gain visibility into all known vulnerabilities in one place. As an added bonus, taking steps to shift API security testing to the left will reduce costs and speed up resolution time.
In addition, once your test workflows are automated, you will also have built-in support for retests: a cycle of testing, remediation, retesting and deployment, keeping your pipeline running smoothly and completely avoiding disruptions. bottlenecks.
A business logic approach to API security testing can increase 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 you go, improving its performance over time by ingesting runtime data to better understand the structure and logic of the application.
This would involve creating an adaptive test engine that can learn as you go, developing deeper knowledge of API behavior in order to intelligently reverse engineer its hidden inner workings. Using runtime data and business logic insights, you can get the best of both worlds – the black and white box approach for enhanced visibility and control through automation.
To wrap up
In addition to their growing popularity, APIs also create a greater vulnerability for web applications. Many organizations don’t even know the extent of their APIs and vulnerabilities. Known and unknown weaknesses can easily be probed by hackers through the available APIs.
However, API security testing is often overlooked and handled the same way 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) provides a viable “gray box” option that automates, scales and simplifies the complex process of API security testing.