> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/getting-started-with-snyk-api-web/best-practices-for-deploying-dast.md).

# Best practices for deploying DAST

Best practices for deploying Snyk API & Web DAST scanning

Learn how to optimize your dynamic application security testing (DAST) deployment and avoid common pitfalls.

## Overview

DAST simulates real-world attacks on your web applications and APIs to identify security vulnerabilities. DAST provides valuable security insights, but it performs invasive scans that can affect application performance and behavior.

During a scan, Snyk API & Web:

* Crawls your application URLs
* Interacts with application elements (filling forms, clicking buttons)
* Performs extensive security tests to identify vulnerabilities

Following these best practices helps you deploy DAST safely and effectively.

## Scan non-production environments

Run scans against development or staging environments, not production systems.

Avoid scanning production back offices where administrators manage content, users, permissions, or transactions. DAST scans can:

* Delete users or create unwanted records
* Degrade application performance due to high request volume
* Inject test data that becomes visible to users and potential attackers

{% hint style="warning" %}
When testing for cross-site scripting or SQL injection vulnerabilities, the scanner attempts to inject data into your application. If a vulnerability exists, this test data can appear in your production environment.
{% endhint %}

Use production-like test environments that include web servers and databases you can restore if needed.

## Use test data that replicates real application behavior

Avoid using real data for security testing.

Using production data in test environments can:

* Expose sensitive information in scan results
* Violate data privacy regulations
* Create data leakage risks

Create dedicated test data in a controlled, isolated environment using a separate test organization or user account. This approach supports thorough testing without putting sensitive information at risk.

## Configure authentication with test accounts

Many applications restrict access to authenticated users only. Configure authentication so Snyk can scan deeper into your application scope and identify more vulnerabilities.

Use dedicated test credentials to prevent mixing test activities with real user data.

To learn more about authentication configuration, visit [Configure authentication](/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/configure-targets/configure-authentication.md).

## Exclude features that trigger external actions

During scans, Snyk interacts with every discovered element, including forms and buttons. These interactions can:

* Send email messages
* Create support tickets
* Make expensive API calls
* Generate garbage content

Configure your reject list to exclude URLs and features that trigger unwanted actions. In your target settings, add patterns for:

* Email notification endpoints
* Ticketing system integrations
* Payment processing endpoints
* External API calls

For more information, visit [Use seeds and reject lists](/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/configure-targets/use-seeds-and-reject-lists.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.snyk.io/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/getting-started-with-snyk-api-web/best-practices-for-deploying-dast.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.