Dynamic application security testing (DAST)

What is dynamic application security testing (DAST)?

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 security tools that use this approach.

What is the role of DAST in application security?

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 be used for desktop applications as well, but there are too many user interface variations and technologies to make this practical. Recent advances are making DAST tools available for mobile applications as well.
• DAST solutions are designed to work as part of AppSec automation processes. While dynamic security testing can also 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.

Why is DAST important?

DAST is an important piece of your overall application security strategy because it provides:

• A real-time, outside-in view of vulnerabilities and risks so that security and development teams can see issues they might not find through other testing methods.
• More comprehensive coverage across the entire potential attack surface, covering dynamic content security and API security with deeper insights, including misconfigurations and vulnerabilities in dependencies.
• Scalability and flexibility for modern agile development processes and security audits, with automation and integration features to help build DevSecOps workflows.

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 one of the checks during a DAST scan triggers an application response that suggests or proves a web application vulnerability, the scanner records the exact location and the received response to present to the user. This also 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, and provide information that allows development teams to fix the identified security risks

What is the difference between SAST and DAST?
SAST tools analyze the static source code for potential security issues, while DAST tools probe a running application to identify vulnerable behaviors. You can think of static analysis tools as code checkers and of dynamic vulnerability scanners as attack simulators.

Benefits of DAST Tools

Dynamic application security testing is an essential part of any complete security testing program, alongside other web application security testing methods such as static application security testing (SAST) (white-box testing), interactive application security testing (IAST), software composition analysis (SCA), and manual pentesting. However, DAST also has some distinct advantages over other testing methodologies when it comes to improving security posture:

• Unlike other security testing approaches, DAST scans can be done at many stages of the software development lifecycle and are independent of the frameworks and programming languages used. You can run DAST tests on applications that are already 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.
• Some dynamic security testing tools have problems accessing and testing 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, some DAST tools may interfere with normal application operation when run in production. For example, the testing process may introduce sample data into application data stores or the tests may affect application performance. For this reason, best practice is to run DAST tools in staging or on exact clones of production environments instead of testing directly in production.

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.

What is dynamic application security scanning?

While DAST can refer to both manual and automated testing methods, dynamic application security scanning (DASS) is the subset of DAST that uses only automated testing to evaluate the security of applications in a runtime environment by simulating real-world attacks. Unlike static analysis, which examines code without executing it, DASS interacts with the application as it runs, identifying vulnerabilities such as SQL injection, XSS, and authentication flaws. By mimicking an external attacker's perspective, DASS provides actionable insights into exploitable weaknesses and helps ensure robust security in production-like scenarios. This approach is critical for identifying runtime issues that static methods might miss, enhancing an application's overall security posture.

DAST accompanying technologies

The purpose 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, applications, or even APIs. This is especially important in enterprise environments, where security teams may not have a complete list of all the web assets operated 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.

DAST best practices

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, set up an process to periodically test a recent clone of the current production environment. 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.