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 main characteristics a DAST tool should include, and addresses the key challenges you might face during a DAST implementation.

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

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.

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.

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.

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. Therefore, the seamless integration between asset discovery and security scans is something you should look for in a DAST tool.

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.

Fundamentally, a DAST tool should support the following types of 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.

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.

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.

Targets may be complex and require specific configurations in order to fine-tune the coverage and effectively scan what you really 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 sensible 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.

When the target has complex flows or flows that require very 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.

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. By setting a custom “User-Agent" in the header and configuring the firewall accordingly, requests can be unblocked.
• 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.

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.

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.

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.

A comprehensive scan coverage report is a must-have for a DAST tool so you can be sure a whole target is being covered. An excellent coverage report must allow you to easily spot whether a scan is reaching areas you expect 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.

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 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.

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.

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.

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).

Scans normally cover all the target’s 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.

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 as, for example, a DELETE request.

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.

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 in 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 well 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.

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 in having in 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.

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
• HIPAA

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 very powerful for sharing and keeping a record of important information within your organization.

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

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 a 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.

In alternative, 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.

Implementing a 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 making sure your DAST tool has all 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.

Probely's DAST tool streamlines all this, making it easier to identify vulnerabilities and protect your assets. Why not take it for a spin? Sign-up for a risk-free 14-day trial and see what our API and Web App Vulnerability Scanner can do for you.