Skip to main content

Best practices for a Dynamic Analysis scan

This section provides best practices that we recommend following to configure and use Dynamic Analysis for testing the security of your web applications and APIs. Clear explanations and practical examples help your team set up faster, more reliable, and successful Dynamic Analysis scans. The best practices are intended for application security teams, developers, and DevOps engineers who manage secure and reliable scanning pipelines.

Dynamic Analysis scan checklist​

Use this checklist to ensure a successful Dynamic Analysis scan.

  • Create a test account and disable MFA and account lockouts.
  • Store credentials securely in variables.
  • Test the login script manually to confirm it works.
  • Install the ISM endpoint near the target application.
  • Validate the API specification and upload it.
  • Configure blocklists to exclude trackers and destructive actions.
  • Run a pre-scan and verify it completes without errors.

Authenticated analysis considerations​

Access to a web application typically requires one or more authentication methods. Veracode Dynamic Analysis supports several authentication methods for an authenticated analysis. To avoid scan failures or scan results with little or no coverage when scanning authenticated sites, we recommend the following best practices.

User credentials for scans​

We recommend that you configure test credentials that you use specifically for security testing. Don't use personal, or real user credentials. During the scan, the crawler signs in and tests the target site, which can generate a high number of login attempts and requests. This activity may lock accounts or trigger fraud alerts.

Example: When you scan a banking portal, create a test user with access to common customer pages such as checking, savings, and transfers, but without administrative privileges.

Use a credentials variable and login script​

To protect and manage user credentials without frequently updating your Dynamic Analysis configuration, use a credentials variable and a login script with the REST API.

Instead of storing passwords directly in scan configurations, save them in credential variables. You can rotate these variables without changing the scan setup.

Example: A Selenium login script might reference ${USERNAME} and ${PASSWORD} variables, which the scanning system fills in securely.

Disable password lockout​

The scanner uses various sign-in methods and authentication combinations to access your site. To prevent account lockouts during scans, we recommend disabling password lockout features, if possible.

If the scanner retries login attempts, it may trigger account lockouts or password reset workflows. To avoid this, either configure the application to exempt the test account from lockouts or block the Forgot Password URL in the scan scope by using the blocklist feature in the scan configuration.

Suppress password resets​

In a web application, pages that support personalized logins often display a reset password link or input field. To prevent the scanner from resetting the password during an analysis, we recommend that you prevent the scan from interacting with this feature. If you know the URL for the password reset feature, you can add the URL to a blocklist to prevent the scanner from accessing the related link.

Disable Multi-Factor Authentication (MFA)​

We designed Dynamic Analysis to run with minimal user interaction. If your site requires MFA, the scanner cannot prompt for or provide the required token during scanning. If your organization permits, disable MFA for the specific test account used by the scanner. This ensures that the scanner can sign in and out of the site repeatedly without encountering lockouts.

Example: Instead of using an OTP-based login, create a dedicated bypass account with a long, complex password for scanning purposes.

Reduce network latency​

The responsiveness of the target web application can affect the duration of the Dynamic Analysis scan. To reduce network latency during scanning, consider the following configurations when planning a Dynamic Analysis.

  • Schedule the scan to run during low load-times so that the site can respond quicker to the many requests from the Dynamic Analysis. Compared to a human user who might interact once with one component of the web application, a Dynamic Analysis sends multiple requests to the same component while performing tests.
  • If you are using Veracode Internal Scanning Management (ISM), install the ISM endpoint close to the target web application to minimize the number of hops between the Dynamic Analysis requests and the application. For example, install the endpoint in the same datacenter or network segment as the target application.

Optimize Dynamic Analysis scans​

Dynamic Analysis assumes that your target web applications use the supported technologies and are operating under normal network conditions. However, there are factors that might impact scan speed, overall performance of the Dynamic Analysis, and the results. The following best practices explain how to use the Coverage Report from a Dynamic Analysis to identify potential performance issues, resolve them, and get the results you want.

Run an initial analysis to assess your site​

We recommend running the first analysis of a new web application without setting limitations that might influence scan coverage or affect results. You can use the first scan as a reconnaissance analysis, where it can freely explore your web application and populate the Coverage Report with as much detail as possible.

After completing the initial analysis, you can review the Coverage Report for the web application. The report provides detailed analytics and patterns of behavior that you can use to optimize the scan configuration.

Third-party traffic to your site does not affect scan time. If you notice latency or unusually long scan times, contact Veracode Technical Support.

For additional information on reducing scan times for web applications, see this Community article.

Example: On an e-commerce site, the initial scan may discover pages such as /products, /cart, and /checkout but may not reach /user/settings. You can then add /user/settings to the allowlist to include it in future scans.

Minimize duplicate content​

Veracode Dynamic Analysis includes a Similarity Threshold option that automatically performs redundancy checks to identify similar, or redundant, content across all pages of a web application. However, some web applications might also create content in certain ways, such as generating content based on user interaction, but only a human can determine whether the same code functionality generated that content.

You can review the Coverage Report to determine whether your web application contains similar content that you can exclude from scanning. You can also adjust the Similarity Threshold to control the level of these redundancy checks.

Exclude URLs that point to similar content​

The Coverage Report provides a list of all scanned URLs. If these URLs point to web applications with similar content, you can use the URL-Specific Allowlist and Blocklist option to exclude these URLs from scans. Excluding similar content can improve the scan results and reduce scan time.

You might have web applications that link to external ad servers or trackers that track user behavior. Teams, such as Marketing, within your organization use the analytics and other useful information from these trackers to learn about your users. A Dynamic Analysis scan does not crawl these links, but it loads them to ensure the web application has all required third-party resources for the analysis. If the application contains several links, the load time might increase the scan time. These links also appear in the Coverage Report, under Ignored URLs. To exclude these links from your Coverage Report and, depending on the number of links, reduce the scan time, add them to your blocklist.

You can review the Coverage Report to identify links to trackers and use the URL-Specific Allowlist and Blocklist option to exclude these links from scans.

Example: Block URLs that contain ads or analytics to prevent them from being scanned.

A web application might expose links that provide access to areas for deleting application data or resetting user accounts. These links are typically accessible to users with high-level permissions, can disrupt scans, and can affect the results.

To ensure the test user account for Dynamic Analysis scans cannot access these areas of the application, either disable the appropriate permission on the account or use the URL-Specific Allowlist and Blocklist option to block access.

Expand the scope of the scan​

If the scope of your scan configuration is too narrow, it can miss areas of the web application that contain vulnerabilities.

Include subdomains​

If your web application has subdomains that require security testing, ensure you add the URLs for these subdomains to the allowlist. During scanning, the crawler can use the URLs to transition from one subdomain to the next without running into access issues. When you include all required subdomains in the same scan, you can generate a single report for the entire web application. If your web application uses subdomains that require security testing, add their URLs to the allowlist. This allows the crawler to navigate between subdomains without encountering access issues. Including all relevant subdomains in a single scan ensures that you receive one comprehensive report for the entire application.

Example: Applications often span multiple subdomains, such as app.example.com and auth.example.com. If these subdomains are not included, parts of the application will not be tested.

Include directories and subdirectories​

If the content of a web application is organized by directories on the same root domain, configure the Directory Restrictions options to specify the directories and subdirectories you want to scan.

API scanning and specifications​

APIs often require more explicit configuration than web applications.

Fix relative URLs​

If an API specification uses relative paths, ensure that a proper server or basePath is provided.

Bad example: /api/v1/users

Good example: https://api.example.com/api/v1/users

Validate the API specification locally​

Run the following command before uploading the API specification. This catches structural errors early and ensures a smooth scan.

swagger-cli validate api.yaml

Include parameter values​

Dynamic Analysis injects a dummy value for any method parameter that does not have an example or default value specified. Providing explicit values improves the accuracy of the scan.

Scripts and custom authentication​

Some applications use custom JavaScript, token exchanges, or multi-step logins. Use scripts to ensure Dynamic Analysis can authenticate easily.

Use Selenium login scripts​

Selenium can simulate real browser actions such as clicking buttons, filling forms, and waiting for elements.

Example script:

driver.get("https://app.example.com/login")
driver.find_element_by_id("username").send_keys("${USERNAME}")
driver.find_element_by_id("password").send_keys("${PASSWORD}")
driver.find_element_by_id("login-btn").click()
driver.wait_until_element_present("dashboard")

Keep scripts simple and reliable​

Focus scripts only on logging in. Avoid extra navigation or actions that could confuse the crawler.

Request-modification scripts for APIs​

If your API requires tokens in headers, configure the script to inject them automatically.

Example (pseudocode): request.headers["Authorization"] = "Bearer " + getToken()

Internal Scanning Management (ISM)​

For non-public internal facing apps, ISM is critical.

Deploy endpoints close to targets​

Install ISM in the same data center or VPC as the application to reduce latency.

Example: If your application runs in AWS us-east-1, deploy the ISM endpoint in the same region.

Follow hardening practices​

Keep ISM software up to date and secure all credentials. Restrict network access wherever possible.

Use diagnostics and logs​

Before you run a scan, review ISM logs or use the diagnostic tool to confirm connectivity and readiness.

Network & Performance Optimization​

Dynamic Analysis scans can be sensitive to response times. Optimize your network and site configuration to ensure reliable scanning.

Scan during off-peak hours​

If your site experiences high traffic during the day, run scans at night to reduce timeouts and improve performance.

Block external calls​

Prevent the scanner from waiting on third-party trackers, such as google-analytics.com.

Limit duplicate content​

Exclude pages that generate similar content (for example, /search?q=a, /search?q=b, /search?q=c) to reduce scan time and avoid redundant requests.

Pre-scan checks & troubleshooting​

Performing pre-scan validation helps prevent wasted scans and ensures accurate results.

Run prescan diagnostics​

If prescan fails, verify:

  • DNS resolution
  • TLS certificate validity
  • Firewall rules

Understand scan statuses​

Healthy scan statuses include:

  • Prescan success
  • Scan started
  • Scan completed

Statuses that require attention include:

  • Authentication failed
  • Connection error

Debug authentication issues​

Manually test Selenium scripts to ensure that login works as expected. If MFA or account lockouts are still active, update the test account configuration or policies.

Selenium Script Tips​

Writing good Selenium scripts ensures reliable and efficient scans.

Use stable selectors​

Prefer element IDs or data attributes instead of XPaths, which can break with minor HTML changes. Example: Use driver.find_element_by_id("login-btn") instead of driver.find_element_by_xpath("//button[2]")

Avoid blind waits​

Use explicit waits for specific elements to appear.

Keep secrets out of scripts​

Don't hard-code passwords or other credentials. Always reference credential variables.

Review results and reports​

Carefully reviewing scan results helps improve coverage and accuracy for future scans.

Use the coverage report​

Check which pages were crawled. If important pages or flows are missing, update the allowlist or associated scripts accordingly.

Review application interactions​

Watch the video to see how the scanner interacts with a web application. This can be invaluable to debug login flows.

Last updated on