How to avoid API blind spots in web application security testing

Test early, test often

Industry experts agree that application security testing should start as early as possible in the development process. Shifting left is the usual term for this practice, though, as we’ve written before, extending left would be a better term – security testing really needs to cover all phases of the application lifecycle, up to and including production. Whatever the name, it is clear that halting the development pipeline to wait for security testing results is not an option in the age of agile DevOps and that modern AppSec must be part and parcel of the software development process.

So much for the theory and industry buzzwords, but the devil is in the details. In the real world, doing web application security testing in a way that covers the entire attack surface while also fulfilling requirements such as test accuracy and efficient workflow integration is a tall order. And let’s not forget that modern applications are far more than collections of web pages – they are complex constellations of web services communicating through application programming interfaces, or APIs. So where do these web APIs fit into the security picture?

Cover everything, not just the visible pages

There are many different ways to test software security, but any AppSec toolbox should include at least dynamic testing (DAST) in the form of vulnerability scanning combined with periodic penetration testing. This gives you the most realistic and comprehensive view of your security posture because you are probing your application environments using the same methods and entry points that malicious hackers have at their disposal. All the potential entry points put together make up your attack surface – and this includes both the user interface and all exposed APIs.

When examining a web application from the outside, the first step is to run a crawler to discover all the elements you need to test. This is where you run into the first big difference between websites and web APIs: you can’t crawl an API like you can a web page. The only way to be sure that you are fully testing all the web APIs in your application environment is to always have the latest API definitions – and these are created and maintained by your developers.

In large development environments that include thousands of API endpoints, it is unrealistic to ask developers for the API definition files every time you need to run a vulnerability scan, especially as development pipelines are heavily automated and any manual intervention consumes precious time. The realistic way to do this is to automatically store and update API definition files to a central location where an integrated vulnerability scanner can fetch them before each scan. However, to make full use of this data in your security testing workflow, you need an automated application security testing solution that can not only integrate with the development lifecycle but also run vulnerability tests for the relevant API types.

Make APIs an integral part of your secure SDLC

In a world where web applications send far more data through APIs than user interfaces, application security testing must keep up or risk leaving much of the web attack surface untested and vulnerable to attack. Even APIs that are internal by design will often be accessible to determined attackers, opening up direct channels to back-end systems that hold sensitive data. On top of that, APIs are specifically designed for silent and automated access, which makes them easier to probe without arousing suspicion.

Knowing all this, threat actors are now shifting their focus towards API attacks, hoping to harvest the low-hanging fruit of insecure web APIs and services to directly access sensitive data or perform unauthenticated operations. With so many web applications now being built as a visual front-end interacting with hundreds of autonomous web services running on back-end systems, bypassing the user interface and going straight for the data seems the obvious choice for cybercriminals – and attacks targeting APIs are indeed on the rise.

An AppSec program that explicitly includes API vulnerability testing is the only way to go to avoid a massive blind spot in your security posture. Learn why covering your APIs is a critical requirement for effective AppSec and how Invicti makes it possible to seamlessly incorporate web API vulnerability testing into your secure SDLC.

Get the Invicti white paper: Cover Your APIs – Securing Your Hidden Web Attack Surface