> 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/can-i-scan-a-production-site.md).

# Can I scan a production site?

Snyk cannot recommend or assume liability for any damage to your site resulting from a target scan. However, the risk varies significantly depending on your application type and configuration.

{% hint style="warning" %}
The following guidance helps you assess the risk, but you are responsible for determining whether scanning your production environment is appropriate for your use case.
{% endhint %}

## Administrative back offices (high risk)

Do not scan production environments where you can manage users or site content.

Scanning administrative interfaces in production can result in:

* Deleted users
* Unwanted content added to your site
* Modified permissions or configurations
* Corrupted transaction data

While Snyk API & Web blocklists URLs and buttons such as **Delete**, the risk of harmful actions remains significant.

## User-generated content applications (high risk)

Do not scan production environments where users can insert content that other users can view.

Scanning these applications in production results in:

* Attack payloads appearing as random content on your site
* Visible security test data in public-facing areas
* Potential confusion or concern for legitimate users

Examples include social platforms, forums, or content management systems with public-facing output.

## Isolated user or organization scopes (low risk)

Applications where users or organizations do not interact with each other present low to very low risk for production scanning.

In these applications:

* All actions are performed within the scope of a user or organization
* Data added or changed by users is visible only to users from the same entity
* Test accounts can be isolated from real user data

For example, in a customer relationship management (CRM) application where each organization has multiple users, create a testing organization and a testing user account specifically for Snyk. This isolates test data and minimizes risk.

Even in low-risk scenarios, use dedicated test accounts and configure authentication to ensure scans stay within isolated test environments. Visit [Best practices for deploying DAST](/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/getting-started-with-snyk-api-web/best-practices-for-deploying-dast.md) for additional guidance.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.snyk.io/scan-fix-and-prevent/scan-with-snyk/snyk-api-web/getting-started-with-snyk-api-web/can-i-scan-a-production-site.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.