Top 5 Tips to Choose the Right DAST Tool

Ensuring the security of your web apps and APIs against threats is crucial, and a Dynamic Application Security Testing (DAST) tool plays a central role in this process. This article explores the key characteristics a modern DAST tool should include, especially as development teams increasingly leverage AI coding assistants. We'll address the challenges you might face during implementation and how to ensure your security testing can keep up with the speed of innovation.

By using the advanced and streamlined features of Snyk API & Web, we’ll explore the core aspects of what makes a successful DAST implementation, such as identifying assets, conducting effective security tests, handling results efficiently, and integrating features into your development pipeline. 

1. Asset Discovery

Organizations are prone to malicious cyber-attacks through the assets they expose in their attack surface. As such, understanding the attack surface and taking effective measures to protect it is fundamental. This has become even more critical as AI tools can accelerate the creation of new microservices and APIs, sometimes faster than security teams can track.

Knowing the attack surface

A DAST tool with asset discovery is crucial for obtaining the inventory of your organization’s assets and understanding its attack surface. Because security threats are always evolving, this DAST tool must also be capable of keeping this inventory up to date by regularly running asset discoveries.

Analyzing the attack surface

The DAST tool should have all the necessary features to facilitate the analysis of the discovered assets to identify and prioritize the most critical ones. For example, it could provide a preliminary risk score to grasp how critical an asset is, screenshots to ease the identification of assets, or IPs to know where assets are reached.

Seamless integration with security scans

Once you determine which assets are more critical in your attack surface, you will want to test them to identify security vulnerabilities in detail to effectively protect them. Thus, the seamless integration between asset discovery and security scans is something you should look for in a DAST tool. 

2. Targets for security scans

A target is what you want to scan to identify security vulnerabilities. Whether you use assets from asset discovery as targets or create standalone targets yourself, the DAST tool should support different types of targets and provide all the means to configure them to achieve the best security scan results. These are the aspects you should take into account while choosing your DAST tool.

Types of targets

Fundamentally, a DAST tool should support the following types of targets:

Web targets

A DAST tool should support the most common types of web apps running on browsers:

• Modern Single-Page Applications (SPAs): These apps provide a great UX by often relying heavily on client-side rendering, supported by a backing API. The DAST tool must be able to scan the client-side app as well as the backing API, even if it is under a different host.

• Traditional web apps: These apps perform most of their logic on the server side, meaning that each page results from a response to an HTTP request to the server, which takes slightly more time to react to user interactions. This is the basic target type that any DAST tool should be able to scan.

API Targets 

Consider a DAST tool that supports APIs with the most common specification formats:

• OpenAPI: It is a standard API specification that tools can use to generate code, documentation, test cases, and more. The DAST tool should be able to use this standard format to determine which API endpoints to scan. If you want to ensure you have valid OpenAPI specifications, try the Swagger Editor.

• Postman Collection: This is a way of reaching an API through a predefined collection of requests to the API endpoints using Postman and, additionally, taking advantage of pre-requests and tests to set environment variables and manipulate data. The DAST tool should be able to consume these collections and execute their requests to scan the API endpoints. It’s fundamental that the Postman collection has a working sequence of requests to the API endpoints that can be called multiple times. 

Targets with authentication

If a target has authentication, it means that it has areas only accessible by authenticated users. The DAST tool must allow authentication to be configured to log in and reach those areas reserved for authenticated users only. Consider the following authentication features:

• Login form: When the target has a login form for authentication, the DAST tool should provide a way to identify the login page and configure the credentials needed to log in successfully.

• Complex logins: When the target has complex login flows (e.g., multi-step logins), the DAST tool should provide a way to configure the sequence of steps and input values to log in successfully.

• Custom authentication headers/cookies: This is yet another interesting authentication feature to have in a DAST tool since it allows supporting even further authentication scenarios, such as when the authentication workflow is based on an email with a login link sent to the user. 

• Login with 2FA: When the target requires Two-Factor Authentication (2FA) to log in, the DAST tool should provide a way to configure it in addition to the two previously mentioned authentication features.

• Logout detection: Some targets can log you out automatically (e.g., when the session expires after a while), and the DAST tool should provide a way to configure and identify logout situations to log back in so that scans keep having access to areas meant for authenticated users only.

Adjust the target’s coverage

Targets may be complex and require specific configurations in order to fine-tune the coverage and effectively scan what you need. In that sense, a DAST tool should have features to adjust the scans to reach the expected areas under the target scope:

• Add access to “hidden” areas: Sometimes, reaching certain areas in the target scope may not be possible just by crawling the target. For example, imagine a target like https://example.com has an area only accessible through a direct link, such as https://example.com/back-office. In these cases, the DAST tool should provide a way to add these “hidden” areas to the target’s scope.

• Restrict access to critical areas: If the target has sensitive areas that should not be considered during the security tests (such as pages with forms that send emails to users), the DAST tool should provide a way to configure these areas and exclude them from the target’s scope.

• Add access to extra hosts: Some targets resort to functionality from services in other hosts. For example, imagine the target https://example.com makes requests to an API in another host like https://api.example.com. The DAST tool should allow extending the target’s scope to other hosts.

Custom navigations for complex targets

When the target has complex flows or flows that require specific values (like forms with combinations of input values that depend on one another), the DAST tool should provide a way of creating and running custom navigation sequences to execute these flows as intended and reach more areas in the target.

Custom headers and cookies for specific behaviors

A DAST tool that allows for setting specific information in headers or cookies can be fundamental to identifying the DAST requests. It can have multiple applications, such as:

• A firewall is blocking DAST requests to the target due to the user agent. Requests can be unblocked by setting a custom “User-Agent" in the header and configuring the firewall accordingly.

• The target has a “human check” (like a CAPTCHA) that blocks DAST requests. By sending custom information in a cookie, the target can have logic to disable the “human check” and allow the security scan to proceed.

Access to targets blocked by WAFs

If you are using a Web Application Firewall (WAF) in front of your target, it can interpret requests from the DAST tool to the target as malicious attacks. This can result in blocked requests and cause the target scan to fail short. To avoid that, the DAST tool should provide its IPs so that you can configure the WAF to whitelist them and unblock scans.

Targets in inaccessible private networks

Sometimes, targets are not public and live in private networks, which makes them inaccessible from the outside world. The DAST tool should provide features to allow configuring access to those private targets.

3. Scanning targets

Once you have defined a target, a DAST tool must crawl the target to explore all achievable areas to cover as much of the target’s scope as possible. Then, the DAST tool must perform extensive security tests in those areas to identify the maximum number of vulnerabilities.

Scan coverage

A comprehensive scan coverage report is a must-have for a DAST tool, so you can be sure the whole target is being covered. An excellent coverage report must allow you to easily spot whether a scan is reaching areas you expect it to. Of course, this also means that you know your target in-depth and all the areas you want to be covered so that you can obtain valuable insights and get the most out of the coverage report.

Tested vulnerabilities

It is paramount to guarantee that the DAST tool has an excellent list of vulnerabilities it can test against, and that it is updated regularly to support the detection of the most recent vulnerabilities. Your DAST tool should provide you access to that list and how often it is updated, so that you can assess whether it meets your security requirements. This includes both traditional vulnerabilities and new types of logical flaws that can be introduced by AI-generated code.

Scanning specific technologies

A DAST tool that detects technologies in targets (for example, PHP, React, or Linux) provides valuable information for security scans, allowing fine-tuning the security tests for those technologies and obtaining better results. Some DAST tools even allow configuring the technologies in targets beforehand to ensure they are taken into account. 

Scheduled scans

Running scans periodically is important to keep the list of identified vulnerabilities in your targets always up to date. In this sense, having scheduled scans is a great feature for a DAST tool since it allows you to automate these aspects without needing your manual intervention.

Pause and resume scans

Pausing and resuming scans is a DAST feature you should consider since it allows you to handle critical situations. For example, if you detect a scan impacting an application's normal operation, you can simply pause that scan and resume it at a more convenient time.

If the DAST tool supports blackout periods, it's even better. You will ensure that the tool automatically pauses scans for you during well-defined periods (for example, during working hours) and automatically resumes them later on in "safe" periods (for example, at night).

Partial scans

Scans normally cover the target’s entire scope, which means they can take some time to finish and for you to get the results. In some situations, you may not need to scan the whole target again after the first full scan, so it might be useful to narrow the scope of the scans to the target areas that interest you. These are called partial scans, and if the DAST tool allows them, you should be able to have configurations like:

• Reduced scope: Scans only cover a determined set of areas you configure that are important to scan again in a target.

• Incremental: Scans only cover what is new and/or has been updated in a target.

Custom scan profiles

Having custom scan profiles in a DAST tool is important for fine-tuning specific scan behaviors. Here are some examples of typical usage of custom scan profiles when you want to:

• Focus on critical vulnerabilities: You define a custom scan profile focused on identifying only the most critical vulnerabilities, which are the ones that are more urgent to fix.

• Focus on speed: If you have targets that can handle many requests, you could create a custom profile for running scans that send more requests in parallel. Thus, reducing the time to get results. 

Non-intrusive scans: In targets where you want to ensure you don’t perform destructive operations, you could have a custom profile to scan targets without testing destructive requests, such as a DELETE request.

4. Findings from scans

As you scan targets, the identified vulnerabilities should be compiled into findings with all the information you need to know about where your targets need protection and how to enforce it. The DAST tool must provide this valuable information and all the features to facilitate handling and managing findings to address them efficiently.

Findings accuracy

This is one of the most important factors related to findings because if the identified vulnerabilities are not trustworthy, it can create disbelief and discredit the DAST tool. You must ensure that the tool provides accurate findings, namely:

• A low rate of false positives: If the DAST tool incorrectly identifies a normal or benign activity as a vulnerability, it will generate a false positive. A high rate of false positives can cause you and your organization to waste a lot of time investigating and addressing “issues'' that are not actual threats and create discredit.

• A low number of false negatives: This happens when the DAST tool fails to detect real vulnerabilities that you know exist. Try to compare the obtained findings for a real target you have and know its actual vulnerabilities. Avoid using common testing targets or with fake vulnerabilities (e.g., for education) since the results may not be trustworthy. 

• A consistent detection: The DAST tool must be consistent and keep findings updated in subsequent scans while they are not fixed. On the other hand, it must stop reporting findings once the identified vulnerability is fixed.

Valuable and useful information in findings

When analyzing findings, the DAST tool must provide you with as much valuable and useful information as possible. Only with that will you be able to make informed decisions about each finding and take effective and efficient measures to protect your targets. 

Here’s some interesting information you should consider having in your findings:

• The description of the vulnerability.

• Where it was found in the target.

• The vulnerable injection point.

• The risk and CVSS score of the finding.

• The evidence that proves the vulnerability. 

• The details of the executed request(s) and received response(s).

• Information on how to fix the vulnerability.

Sharing findings

It’s important that the DAST tool provides reports about the findings and scanning conditions to share with other teams within or outside the organization. These reports must contain the necessary information for the audience with whom you are sharing it to be able to analyze and make decisions autonomously, with little or no support from your side. For example, if you share a report with an executive team, you may want only an overall summary, while if you share it with a security team, you may want a report with much more detail. 

Depending on your organization’s requirements, it can also be a plus for the reports to include information about compliance with some of the most important standards, such as PCI DSS, OWASP Top 10, ISO 27001, and HIPAA.

Handling findings

While analyzing the findings and making decisions on what to do with them, the DAST tool should provide the necessary features for acting upon those findings according to the decisions you make. For example, some useful actions can be: 

• Re-test: Instead of running a complete scan, you can simply re-test a specific finding and easily check whether the vulnerability identified in the finding has been effectively fixed. 

• Accept the risk: In some specific contexts, the vulnerability doesn't represent any risk to the organization or is already known and can be considered acceptable, so you should be able to mark the finding with acceptable risk.

• Set as invalid: If you reach the conclusion that the vulnerability identified in a finding is not exploitable, you should be able to mark the finding as invalid and report it as a False Positive. 

Add notes: Adding notes to findings can be powerful for sharing and keeping a record of important information within your organization.

5. Integration and automation

If you want to improve efficiency in your organization, the DAST tool should provide ways for shifting security testing left. This means introducing security testing sooner in the software development lifecycle (SDLC) through integration and automation.

Management solutions or issue trackers integration

In case your organization uses an issue tracker for managing tasks (or a vulnerability management tool to centralize vulnerabilities), the DAST tool of your choice should allow two-way synchronization. This way:

• The DAST tool can create issues automatically in the issue tracker when it finds new vulnerabilities. 

• Once your team fixes the new vulnerability, the DAST tool performs a retest.

• If the vulnerability persists after the retest, the DAST tool reopens the issue.

Start by focusing on high-risk web apps or APIs, and work with those teams first. After having everything running smoothly, expand the process to other teams. This way, you can improve the security issues’ fixing process, integrating it into the development lifecycle of your teams.

CI/CD pipelines automation

Alternatively, you can automate the DAST tool within your CI/CD pipelines. If the DAST tool supports this type of automation, you can automatically trigger security testing in different environments (from development to production).

Although this will allow you to integrate security testing into the software lifecycle without manual intervention, it will add more steps to the CI/CD processes and can change your teams’ workflow. That’s why it is so important to assess the impact of automation with each team and bring in DevOps to the conversation to understand the necessary changes and plan accordingly. 

Simplifying DAST implementation with Snyk API & Web 

Implementing an AI-powered DAST solution effectively is essential for securing your web apps and APIs against potential threats. And it begins with thorough asset discovery, which helps you understand and manage your attack surface. By knowing exactly what assets you need to protect, you can configure your targets more accurately, ensure that your scans are comprehensive, and, once you have findings, ensure they are accurate and manage them effectively. All this while integrating the DAST tool with your existing workflows.

By ensuring your DAST tool has all the key factors outlined in this article, you can enhance your organization's security posture and ensure that your assets are well-guarded against evolving cyber threats, including those whose code is generated by AI.

Snyk API & Web, a key part of the Snyk AI Trust Platform, streamlines this entire process, making it easier to identify vulnerabilities and protect your assets. By integrating our developer-first DAST capabilities into your existing workflows, you can secure your applications, empowering your teams to innovate securely with AI.

Why not take it for a spin? Sign up today and see what Snyk API & Web can do for you.