Overview of Dynamic Application Security Testing

Dynamic Application Security Testing, also known as DAST, is a form of testing a running version of your application to identify potential security vulnerabilities. With DAST, a scanner sends requests to your application that simulate malicious attackers and evaluates the response received from the application for an indication of a security bug. As they run through the test suite of simulated attacks, any potential vulnerabilities are recorded for review.

DAST scanners have long been a favorite tool of enterprise security teams, software engineering teams, and penetration testers alike. This form of testing finds vulnerabilities that your team has introduced as well as exploitable vulnerabilities from open source components used within the application. It is often used alongside Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools. DAST is known for their low false positive rates and clear surfacing of application security risk.

By leveraging dynamic application security testing, companies have visibility into vulnerabilities within their application. When automated in the CI/CD pipeline, companies can ensure that these vulnerabilities are caught before they are shipped to production.

How it Works

DAST scanners start with pointing at the host where your application is running. This may be a publicly available website or web app, but it is generally advised to run DAST scans against a pre-production environment. Given that the scanner simulates an attacker, it can potentially modify or erase data in your production environment, which has obvious negative implications (Learn more in our posts about why you should not run DAST against production and how to seed a database for DAST scanning).

Once the scanner is pointed at the host, it will start an HTML spider to identify all possible paths and actions. Depending on the tool you are using, it may also use an ajax spider for single page applications, OpenAPI specification for testing your REST APIs, or even look at the GraphQL  introspection endpoint to identify your GraphQL API query tree. Ideally, your tooling should cover as much of your application and backing APIs as possible and should do so in an automated fashion.

Then, the scanner begins running a suite of tests, sending requests to all of the identified paths/endpoints and looking for responses that would indicate a security vulnerability. In many ways, you can think of this as negative testing – is the application returning a response when it should not be?

Any findings are then displayed in the report or platform of your DAST scanner, ideally with the pertinent information that a developer would need to fix the bug.

What it Finds

DAST scanners find a wide variety of security vulnerabilities. This can include SQL Injection, Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and many other vulnerabilities. These scanners find the majority of the OWASP Top 10 vulnerabilities. For a sample of the types of vulnerabilities that are identified by DAST scanners, check out the tests run by open source ZAP, the most popular application security testing tool.

The OWASP Top 10 vulnerabilities that are not found by DAST scanners are because they cannot be found generalized automated testing. Some DAST tools, however, are introducing custom script support that allows for testing of complex business logic or vulnerabilities specific to your application. Examples of this include broken authentication or cross-tenancy checks.

DAST Options: Getting Started and Evaluating Tools

One benefit of dynamic application security testing is that getting started is easy. With testing automated within the tool, you can get started with as little as pointing the scanner at your host.

Whether you are looking to expand your enterprise application security program or are just getting started with your first application security tests, there are solutions that will support you. The following information provides a list of the leading solutions in the space as well as criteria for consideration when selecting a tool

DAST Products and Tools

There are many DAST tools on the market, including several open source or free options. Below is a list of the leading tools in the space that you could use for testing.

  • ZAP: ZAP is an open source DAST scanner. ZAP is the most widely used application security scanner, has been an industry standard for 10 years, and is built for automation. ZAP supports scanning with a desktop application and also supports automated scanning via API.
  • StackHawk: StackHawk is a modern DAST tool built for automation in CI/CD. For teams that want to catch vulnerabilities before they hit production and integrate security testing into engineering workflows, StackHawk is the leading option. StackHawk is built on top of the open source ZAP project and provides engineering teams with simplified automation, vulnerability triage, and fixes of securing findings.
  • Burp Suite: Burp Suite, a product of PortSwigger, is a penetration testing tool. For penetration testers or in-house application security teams looking to do manual scans, Burp Suite is an excellent tool. There is also an enterprise edition that leverages agent deployments.
  • Detectify: Detectify is a more modern entrant in the DAST space, although it leverages a crowd sourcing approach to identifying vulnerabilities. The DAST scanner runs against production applications on a schedule.
  • Netsparker: Netsparker is an established DAST tool that supports enterprise security teams. With on-premise deployment and a professional services arm to lead rollout, Netsparker fits enterprises that are not yet investing in DevSecOps.
  • Rapid7: InsightAppSec is the DAST solution provided by Rapid7, another long standing enterprise security platform. InsightAppSec supports on-premise deployment and scheduled scans of production, making it another excellent solution for enterprises that are not yet investing in DevSecOps.
  • Veracode: Veracode is an enterprise application security platform with solutions including SAST, SCA, IAST, and DAST. For large enterprises that prioritize a single platform for all application security needs, Veracode may be the right choice.

How to Select a DAST Tool

Once you decide to get started with dynamic application security testing, the hardest part of the process may be deciding which tool is right for you. Below are a few items to consider when selecting a tool.

Scan Frequency: Automated, Scheduled, or Manual

Consider how often you would like to kick off scans. The following options are the most common methods of scannings.

CI/CD Automated Scans

The future of application security is automated and integrated with the DevOps pipeline (known as DevSecOps by many). With automated security scans in the CI/CD pipeline, there are many benefits that lead to faster discovery and fixes, including:

  • Developers are alerted of any new vulnerabilities before they hit production, optionally breaking the build to ensure a review happens before the release
  • Testing can be run against underlying services and APIs instead of the customer-facing application, leading to faster identification of the underlying issue when a bug is found 
  • With tests on every pull request, smaller increments of change are tested, allowing developers to quickly fix vulnerabilities while still in the context of the code they were working on

Scheduled Scans

For teams that are not yet ready to adopt application security automation, they may select to run regularly scheduled scans against the application. While it may be simpler to run a scanner on outside infrastructure and kick off the scan, there are several concerns with this method of dynamic application security testing:

  • Scheduled scans are most typically performed against the production site. Given that DAST scanners actively attack the application, the security tests are often limited in scope to avoid affecting the production environment. This approach, however, leaves the application vulnerable to some of the most malicious attacks.
  • When a vulnerability is found, inefficient internal processes must take place to discover the underlying cause of the bug
  • Production applications contain protections against BOT type activities, such as rate-limiting, that make it harder for a scanner to effectively run testing

Manual Scans

Manual scans are often easy to get started with, but lack scalability across teams. Additionally, findings from these scans are less reproducible for the individuals who are typically deploying fixes. Manual scans that inherit shared configuration from automated testing, however, are highly beneficial in validating fixes.

Authenticated Scans

If your application requires user login, you’ll want a scanner that supports authenticated scans. If you are using an automated or scheduled scanner, this can be more difficult. You’ll want to ensure that the vendor supports your form of authenticated scanning, such as cookie-based, external token, and bearer token.  

Application Target: Production vs. Pre-Production Sites

As mentioned above, there are many benefits to scanning pre-production vs. the production application, including the ability to catch vulnerabilities before they are live, not having to get around rate limiters, firewalls, and WAFs and shortening time to fix.

While the ability to run these scans is partially dependent on the company’s deployment pipeline, there is value in a scanner that is built to support pre-production scanning.

User of Tool: Security Analyst or Engineering Teams

When picking a tool, one of the top considerations should be the individual who will use the tool. While testing and fixing application security vulnerabilities often includes some combo of security and development teams, developer-centric security tooling is growing in popularity.

These tools are increasingly being used with a focus on enabling developers to make triage decisions and deploy fixes in their existing workflows, with the security team responsibility shifting to risk based guidance oversight.

API Security Testing

The application security testing landscape has shifted over the past decades, with APIs serving as a primary potential attack vector. If you are running application security testing against modern applications, ensure that the tooling you select supports API testing as a first class part of the tool.

Additionally, if you are using GraphQL as part of your tech stack, you’ll want to ensure that GraphQL API testing is supported by your DAST tool. You’ll also want to ensure that the tool supports scanning federated GraphQL implementations.

Single Page Application Security Testing

Single Page Applications (SPAs), built in frameworks like React or Angular, have rapidly grown in popularity in recent years. Without a static DOM, traditional HTML spiders cannot identify the various paths to run a dynamic application security test against. Testing SPAs requires a tool that supports an ajax spider, as well as a tool that can scan the underlying APIs.

Deployment Model: On-Prem vs. SaaS 

In determining the right application security testing tool, you should be sure to consider the deployment model that works best for your organization. Most companies will prefer a SaaS solution, but some companies still require an on-premise solution.

Conclusion: Just Start Testing

Dynamic application security testing is an excellent way to ensure that you are delivering secure applications and avoiding the risk of a breach. Getting started is relatively simple and there are numerous free and open source tools to support your testing. The takeaway here is to just start testing!