Deployment: Invicti Platform on-demand, Invicti Platform on-premises
Scanning production environments
Invicti Platform scans your targets to identify security vulnerabilities. To do this, it simulates the behavior of an attacker - crawling the target and sending payloads to detect issues like SQL injection and cross-site scripting.
- During the crawling phase, Invicti acts like a search engine bot to map the target's structure. During the attacking phase, it sends payloads to identify vulnerabilities.
- Invicti is designed to run non-destructive security scans and isn't malicious in intent. Still, it's invasive, and its actions can negatively affect a target.
- This is especially important if you scan a production environment. You may experience performance issues or find unexpected emails in your inbox.
It's critical to identify any links or forms that may result in a status change on your target before scanning a live environment, and exclude them from scanning. This document explains the side effects scanning can cause on production environments and how to minimize them.
Using only non-invasive techniques doesn't allow the scanner to identify the real potential entry points that attackers use. Attackers use any tool and vector available while exploiting vulnerabilities. Invicti uses the same level of effectiveness to find those entry points.
Why this matters
Scanning a live production environment without preparation can cause unintended effects: garbage data written to your database, email floods, and server slowdowns or outages. Understanding these risks before you scan helps you take simple precautions that prevent disruption for real users and keep your scan results clean.
Garbage records and accidental data loss
Invicti crawls and maps the target before starting the attacking phase. Crawled pages may contain input fields for user interaction.
| What happens during scanning | What you can do |
|---|---|
| During the attacking phase, Invicti injects data into the target to identify vulnerabilities like SQL injection and cross-site scripting. This can create garbage comments, posts, or articles in the target's database that become visible to real users. A target without proper input validation and sanitization could also be exploited by a malicious visitor who discovers the same vulnerability. | Before scanning a production target, make sure a backup is available. Exclude specific forms or URLs from the scan scope to prevent unwanted data injection. Consider using a staging environment that mirrors production for thorough testing, and clean any test data after scanning is complete. |
Email floods
Many targets include a form that forwards visitor input to a specified email address.
| What happens during scanning | What you can do |
|---|---|
| Invicti submits forms - including contact forms - multiple times to check for vulnerabilities. Each submission generates an email, which can cause an email flood. If the email address is a group mailbox, many people across departments could receive hundreds of emails during the scan. In some cases, a coding issue can trigger an infinite loop that resembles a DoS attack. Invicti won't intentionally launch a DoS attack, but these side effects can occur because of how the target is coded. | Use a temporary email address during the scanning period, or set up email rules to block or reject emails from the scanner (notifications-noreply@invicti.com). Exclude the form's submit button from the scan scope so Invicti doesn't trigger form submissions. Configure rate limiting on email forms where possible. |
Server slowdown or downtime
Invicti sends requests to the target during scanning. The number of requests depends on the size of the target and the security checks selected in the scan profile. In many cases, Invicti sends thousands of requests to the target host.
| What happens during scanning | What you can do |
|---|---|
| Invicti uses a built-in scan policy optimizer to manage scan speed. You can also configure the number of requests per second - the default is 30, with a maximum of 100. A high request rate can cause connection issues or trigger a DoS event. If the target host can't handle the volume, it may slow down or stop responding entirely, affecting performance for real users and increasing scan time significantly. | Start with a low number of requests per second and increase gradually if the target handles it well. Schedule scans during off-peak hours to reduce the impact on users. Monitor server performance during scanning and adjust the request rate accordingly. |
Overloading the server with requests
Log files can become overloaded if the target treats scanner requests as suspicious traffic.
| What happens during scanning | What you can do |
|---|---|
| Scanning events and errors are recorded in the target's database or log files, and often in the web server's log files too. Invicti can send a large volume of traffic in a short time - up to 100 requests per second. If the target treats this as an attack, it may block requests while still logging them. Without log rotation configured, this can exhaust disk capacity. | Modify the request headers in the scan profile and add the scanner's IP addresses to the trustlist so the target doesn't treat Invicti as a threat. For the correct IP addresses to trustlist, refer to the Trustlist requirements for on-premises document or the trustlist requirements for your region: US, EU, CA. Monitor disk space and log file sizes during scanning, and configure log rotation to prevent disk space issues. |
Troubleshooting
The scan is causing performance issues on the production server
Reduce the number of requests per second in the scan profile. The default is 30 - try starting at 10 or lower. You can also schedule the scan during off-peak hours to minimize the impact on real users.
The scan triggered an email flood
If the scan is still running, pause it and exclude the form's submit button from the scan scope before restarting. For future scans, set up a temporary email address or create filter rules to block emails from notifications-noreply@invicti.com before scanning.
Garbage data appeared in the production database after scanning
This is expected when scanning a live environment with forms that write to the database. Restore from a backup if the data caused issues. For future scans, exclude the affected forms from the scan scope or run the scan against a staging environment that mirrors production.
Need help?
Invicti Support team is ready to provide you with technical help. Go to Help Center