Dynamic application security testing (DAST)

What is dynamic application security testing?

The term dynamic application security testing (DAST) refers to security testing performed on a running application, not static code. The goal of dynamic application security testing is to find and list security vulnerabilities and misconfigurations. Note that the term DAST can apply both to the security testing methodology and to tools that use this approach.

While dynamic application security testing is not limited to any specific types of applications or tools, two things are usually true about the methodology and the tools that use it:

  • The tested applications are web applications. In theory, DAST could apply to legacy desktop applications, but there are no known tools developed for this use case due to the diversity of legacy application user interfaces. Recent advances are making DAST tools available for mobile applications as well.
  • DAST solutions are designed to work as part of automation processes. While dynamic security testing can be performed manually, it is then considered a part of penetration testing.

Other application security (AppSec) terms used to describe dynamic application security testing are black-box testing, vulnerability scanning, and outside-in testing.

How does DAST work?

Dynamic application security testing tools mimic the actions of a black-hat hacker but in a safe way.

  1. The DAST scanner first maps out the application at runtime using a web crawler. To do this, it finds all the application pages, follows all the links, and also finds all functions (for a single-page web app). If DAST is used to test APIs, it follows an API definition document to find every available entry point.
  2. Once the mapping is completed and the vulnerability scanner has the entire map of the web application, it proceeds to access each input location that was found, such as a form field or an API parameter, and perform a set of checks on each of the locations. Security checks send data to the web application and analyze the responses and reactions. The test data is meant to mimic malicious content sent by a black-hat hacker.
  3. When the DAST scan gets an application response to one of the checks that suggests or proves a web application vulnerability, it records the exact location and the received response so they can be presented to the user. This allows a pentester to later reenact the testing scenario manually if required.
  4. Application testing solutions, unlike anti-malware tools, do not perform remediation. Their job is only to find security issues in the application, such as SQL injection or cross-site scripting (XSS) vulnerabilities. All identified security risks need to be fixed manually by development teams.

Advantages and disadvantages of dynamic application security testing

Dynamic application security testing should be a part of any complete security testing program, alongside other web application security testing methods such as static application security testing (SAST) (also known as white-box testing), interactive application security testing (IAST), software composition analysis (SCA), and manual pentesting. However, DAST also has some distinct advantages when compared to other testing methodologies.

  • Unlike most other testing approaches, DAST testing can be done at any stage of the software development lifecycle. You can run DAST tests on applications that have already been deployed without having to modify these applications or their application servers in any way, which is especially advantageous for legacy applications.
  • DAST is independent of the programming language used to create the application. As long as the application has a web user interface (uses HTML, JavaScript, and other front-end web technologies), a DAST tool can test it. More advanced DAST solutions can also test application APIs.
  • Because DAST simulates user actions, it typically has lower false positive and false negative rates than other testing technologies, especially SAST tools.

However, dynamic application security testing also has some disadvantages in relation to other application security testing methods.

  • DAST can only test parts of an application that are already runnable. If the application source code contains sections that have been developed but are not yet deployed, DAST tools will not be able to test these parts.
  • Dynamic security testing tools may find it difficult to access and test sections of the application that are gated by non-standard authentication and authorization mechanisms, and may find it difficult to follow business logic. However, professional DAST tools include manual guidance modules designed to mimic user actions and follow authentication gateways as well as business logic such as complex forms.
  • Without careful tuning, DAST testing may interfere with normal application operation. For example, the testing process may introduce sample data into application data stores or the application may run slower while being tested. That is why not many prefer not to run DAST tools in live production environments and use them on production clones or staging environments instead.

Types of dynamic application security testing

While there are no formal subtypes of DAST, there are tool characteristics that security experts use to informally subdivide DAST tools into two informal groups: modern DAST and legacy DAST. Here are the main capabilities used to distinguish between them:

  • Automation and integration: Legacy DAST tools were designed for ad-hoc manual scanning. While the scanning process itself is performed automatically, there is no other automation available – the tool simply builds and displays a list of found security vulnerabilities. On the other hand, modern DAST tools are meant to be invisible to the user and work in the background as part of the SDLC, usually activated by an automation server such as Jenkins. Scan results are then visible as tickets in the developers’ issue tracker.
  • Vulnerability confirmation/validation: Legacy DAST tools perform simple testing that does not go beyond sending a request, receiving a response, and deciding if the response could signal a vulnerability. They offer no other methods of confirming vulnerabilities. On the other hand, modern DAST tools often perform checks that confirm the vulnerability with 100% certainty and offer a proof of exploitation, thus eliminating the need for manual confirmation by penetration testers or security engineers.

Most DAST tools are commercial products, but there are also some open-source alternatives. However, due to its limited functionality, open-source software such as OWASP Zed Attack Proxy (ZAP) is generally considered legacy DAST. Many related open-source projects are manual penetration testing tools, not application security scanners.

Some DAST tools that are considered modern because they meet all the criteria listed above are Invicti and Acunetix by Invicti. Both these solutions offer full automation and integration as well as vulnerability confirmation.

DAST accompanying technologies

The sole function of dynamic application security testing is to scan an application and find vulnerabilities. However, in most environments, that is not enough. That is why DAST tools either offer extra functionality or come bundled with accompanying software, which may include the following capabilities:

  • Web asset discovery: Most advanced modern DAST solutions are able not only to find vulnerabilities in applications but also to find websites and applications. This is especially important in enterprise environments, where security teams may not have a complete list of all the applications and websites owned by the business.
  • Vulnerability assessment: With larger organizations, the number of vulnerabilities can be in the thousands, making it impractical for security teams to manually go through such lists and prioritize them. Advanced modern DAST solutions automatically assign priorities to vulnerabilities based on different factors such as their potential impact, ease of exploitation, or even the business importance of a particular asset. This lets security teams focus their remediation on security risks that are most likely to lead to severe consequences such as a data breach.
  • Vulnerability management: If the number of vulnerabilities is large, it is almost impossible to manually track the state of resolution. That is why modern DAST tools come with internal systems that allow security teams to mark the state of resolution as well as with interfaces to automatically manage vulnerabilities in issue tracking systems. This includes integrations that can, for example, have the vulnerability scanner automatically retest a vulnerability that has been marked as resolved in the issue tracker.

How to use DAST

The legacy use case for DAST was to either manually scan web assets on an ad-hoc basis or use vulnerability scanning in the last stages of application development, such as on staging servers or production clones. This is no longer the recommended approach. Modern DAST solutions come with interfaces that let you use DAST tools in three different stages of application development:

  • Early development (shift left): Modern DAST tools are designed to be used in a DevOps/DevSecOps environment to test as early as possible, from the first application builds. It is recommended to run DAST scans on a runtime app as soon as possible to eliminate vulnerabilities before they make it to later stages. Security testing should be part of the CI/CD pipeline, just like functional testing.
  • Staging/pre-release: Since the application functionality is often fully accessible only when the entire application architecture is linked together, it is recommended to make security testing part of the pre-release process. The app should be fully deployed as it will be in production and thoroughly tested at that time, independently of earlier development-time testing.
  • Regular post-release (shift right): Scanning with modern DAST tools is not nearly as invasive as with legacy tools and can be fine-tuned to make it safe even in live production environments. Such tuning includes, among other things, making sure that no test data is introduced into a production system or deleted from it, no test emails are being sent, and the volume of requests does not hinder normal app operation.

If you don’t feel comfortable with security testing in a live production environment, make a clone of the current production environment and test it regularly. The recommended schedule is to scan for high-severity vulnerabilities daily and run full scans weekly. Apart from covering any unexpected modifications to the application, such scans may also reveal new vulnerabilities resulting from changes in the deployment configuration or new security checks being delivered with DAST tool updates to account for newly discovered vulnerabilities and exploits.