You’ve probably heard the saying that there’s more than one way to skin a cat. Well, that certainly applies to application security testing. Early on, the two main options for testing websites and applications were running a generic network vulnerability scanner or performing a manual source code analysis. Neither of these approaches were good for finding all the things that matter at the application layer. The expertise, time, and effort involved performing manual source code analyses was out of reach for most as well.

More recently, we are seeing that dedicated web vulnerability scanners do a great job of finding flaws within websites and applications. These scanners are much better at uncovering web-related vulnerabilities compared to using earlier approaches. This type of web security testing is called Dynamic Application Security Testing or, simply, DAST. As IT and security needs have evolved, so have source code analysis tools. Now, rather than manually sifting through thousands and thousands of lines of code, you can simply point and click and get an output of source code related vulnerabilities. This type of web security testing is called Static Application Security Testing, or SAST.

A more recent approach to web application security testing is Interactive Application Security Testing or IAST. This approach, which was introduced by Gartner over a decade ago, combines DAST and SAST capabilities to find security flaws from multiple perspectives rather than simply interacting with the application on the front end or looking at source code.

I’ve had the opportunity to work with each type of web security testing tool and have found that they each have their pros and cons. For example, DAST is great at finding exploitable issues that are both tangible and easily repeatable. DAST is the simplest and quickest way to test any given website, API or application for vulnerabilities. Most importantly I found that DAST is going to find the largest number of meaningful flaws and minimize false positives that are uncovered.

SAST will find a lot of application flaws that could be exploitable. I have found that many of these findings are more theoretical and require the alignment of many variables to happen. SAST is great at uncovering sloppy or otherwise non-ideal code that goes against best practice. Perhaps most noteworthy is the reality that SAST is very good at producing noise. In other words, lots of false positives and even false negatives that end up creating more work for technical professionals when it comes to uncovering the web flaws that truly matter. One nice benefit is that SAST is much closer to the development process. It often takes place within/during the SDLC rather than being more reactive, in the future. This timing provides the benefit of finding security flaws in the process and preventing them from ever making it into production code.

IAST has interesting capabilities that could be considered the best of both worlds of DAST and SAST. Still, IAST is unique in its own ways. With this approach to security testing, you install a module on the server that monitors runtime application data flows, functionality, etc. IAST can find specific lines of code that match up vulnerabilities that are exploitable from the front end of the application.

A big challenge with IAST is that technical teams are often hesitant to install the required local IAST agent on their servers. Or they might insist that staging, testing, or development systems are tested rather than production. In many situations, you must use/invoke the entire application to find all possible flaws. This can be problematic because you’re not actually testing production and may not have access to all application functionality depending on the data involved. For example, outside of production, there likely won’t be the same or even enough data to trigger some of the application’s functionality. Certain application workflows and logic that would otherwise trigger pagination and so on might not happen. Therefore, page numbers or other variables cannot be manipulated and tested in-depth. This is similar to DAST when there’s not a good crawler that can find all parts of the application. In either case, this can be a daunting task given the complexity of many modern applications.

Furthermore, staging, testing, and development systems are often not configured the same as production. When using IAST, there could be gaps that are not uncovered due to the configuration of non-production systems, not only with source code but also the underlying server and related software configurations. If vulnerabilities are found in staging, test, etc. then those vulnerabilities might still need to be validated in the production environment.

The new trend of modern applications makes it more difficult to use IAST. Another potential limitation of IAST are single-page applications (SPAs) that use background APIs. Many such microservices are built by different teams using different technologies. It’s virtually impossible to implement IAST in this regard. DAST, on the other hand, can help with this. For example, when a SPA calls an API and JSON data are returned. If the content type is Application/JSON and includes user inputs to trigger cross-site scripting and similar flaws, when that code is not escaped, then the browser will never render that JavaScript. The vulnerability is then in the browser, so to speak, and SAST and IAST will not find it but DAST can.

I have found that IAST works well with complex authentication workflows. For example, when manually testing, you can ensure proper authentication (especially when tokens and MFA are used), invoke proper application functionality and so on. For complex situations, given the nature of IAST, you might consider running it on your most critical applications but not necessarily all of them.

I really like the benefits offered by all three of these web application security testing technologies. SAST has its place, DAST is great at finding the majority of flaws that the bad guys are going to uncover, and IAST offers some unique approaches to more complex situations. At a minimum, DAST should be your main focus. Step back and consider your application environment, your internal resources and expertise, as well as your budget to determine which approach might be best.

The most important thing is that you are doing something. Practice relentless incrementalism. Work a little bit every day towards improving application security and you’ll be well ahead of the curve.