A Dynamic Application Security Testing (DAST) scanner simulates attacks in your target web applications and APIs (“Targets”) to help you identify security vulnerabilities. DAST is a useful tool for protecting your web applications and APIs from ever-emerging cybersecurity threats, and while its intent is not malicious, it still performs invasive scans and tests in real-time, which could affect your application’s performance.
During a scan, Probely’s crawler goes through your Targets’ URLs and interacts with the application’s elements completing tasks, such as filling out forms and clicking on buttons, among other actions. At the same time, Probely’s scanner performs extensive tests on your target to identify as many vulnerabilities as possible.
There are a few simple best practices you should keep in mind when using a DAST service:
Scan non-production environments
Scan development or staging environments, not production systems. In particular, you should avoid scanning your application’s back office (the part of your site that is used by admins to manage content, users, permissions, transactions, and so on) in a production environment. Scanning production environments can inadvertently delete users or create garbage/spam records.
Scanning production environments may also cause performance degradation in your web application or API due to the amount of requests sent during scans.
Another potential side effect of testing production is having unwanted content changes made to your website. This can happen because, while testing, Probely attempts to inject data into your target’s database to determine if there is a Cross-site Scripting or SQL Injection vulnerability that can be exploited. If such a vulnerability exists, as a result of these tests, our scanner is able to add content to your application, which can be visible to your users and potential attackers.
You should always try to scan an environment closely resembling production, including web servers, databases, etc. that can be easily restored, if required.
Use test data that can replicate real application behavior
Using real data for testing purposes might result in accidentally capturing sensitive information in scan results.
Instead, perform tests in a controlled, isolated manner, using a separate test organization or user. This will allow for thorough tests without putting sensitive information at risk.
Configure authentication and use a test account to log in
Some websites and applications can have restricted areas meant for authenticated users only. For your scans to be more thorough in these targets, you can configure authentication, thus allowing Probely to go deeper into the target scope to identify vulnerabilities.
In addition, using test credentials prevents the mixing of test and real user data.
There are several ways you can configure authentication for your target. If you want to know more about this, check out this article about scanning targets behind the login.
Skip features that send e-mail messages, open tickets, make expensive API calls, etc.
During a scan, Probely will try to interact with every element found in a Target, including filling out forms and clicking on buttons. These interactions can potentially create garbage content on your site, spam your inbox, etc.
To minimize unexpected outcomes, you should disable these features or exclude URLs from your scan. In your target settings, you can configure the Reject List so that some features or pages are excluded from the scans. Check out this article for more information on how to configure the reject list.
If you’re interested in getting the most out of your DAST tool, take a look at the following blog posts: