Scanning Production Environments with Acunetix 360

Acunetix 360 is an automated web application vulnerability scanner to identify issues in the target website. To do this, Acunetix 360 simulates the behavior of attackers during scanning. That is, the scanner crawls and attacks the target web application, web services, and web API.

  • Acunetix 360 acts as a search engine bot to create a sitemap of the target website in the crawling stage. In the attacking stage, Acunetix 360 sends payloads in order to identify, for example, SQL Injection and Cross-site Scripting in the target website.
  • Acunetix scanners are designed to run non-destructive security scans and are obviously not malicious in intent. Still, they are invasive, and their actions can affect a web application negatively.
  • This point is particularly important if you scan a production environment. You may experience performance issues or find lots of email in your inbox.
  • So, it is critical to identify any links or forms that may result in the status change in your website before the scanning of the live environment and exclude them from scanning.


Using only non-invasive techniques does not allow the scanner to identify the real potential intrusion points that attackers can use. These attackers use any and all tools and vectors available to them while trying to exploit vulnerabilities in a website. So, Acunetix 360 will try to identify points of entry with the same level of effectiveness as attackers could.

You can read about various types of effects and how to minimize them in the next section.

Garbage Records and Accidental Data Loss

Acunetix 360 crawls and finds pages on the target web application before starting the attacking phase. Crawled pages may contain input fields for user interaction.

What Happens During Scanning

How to Prevent Damage

  • While attacking the target web application, Acunetix 360's security checks help identify vulnerabilities.
  • Each check will have different effects on the web application. For example, one type of security check may inject garbage data into the web application’s database to determine whether there is a Cross-site Scripting or SQL Injection vulnerability.
  • Although the parameters injected into the database are not harmful, they will create garbage comments, posts, or articles in the web application.
  • This garbage data can be viewed by visitors, and its presence may signal to an otherwise uninformed hacker that a vulnerability exists.
  • If a website form, for example, does not have proper validation and sanitization built in, attackers could inject OS commands or code for malicious purposes.
  • Remember that a vulnerability exploited by Acunetix 360 could also be exploited by a malicious visitor.
  • When you launch scans on test websites, during the crawling phase, Acunetix 360 clicks all elements on the discovered page.
  • If you are launching a scan in a live environment, you should first ensure that a backup procedure is in place to restore critical data in case of accidental loss.
  • If, for example, you have a delete.php page that contains a link or button that deletes a record on the database, Acunetix 360 would click on it during scanning.
  • Naturally, this could damage your website. You can prevent Acunetix 360 from testing delete.php by excluding it from the scan using our Exclude URLs with RegEx option (see Configuring the Scan Scope).
  • You can also exclude HTML elements such as logout links or buttons using CSS selectors (see Causes of Logout During Scanning).

Email Floods

Many web applications have a form that redirects input entered by visitors to a specified email address.

What Happens During Scanning

How to Prevent Damage

  • Acunetix 360 submits application forms or simple contact forms multiple times to check for vulnerabilities. The form generates an email each time Acunetix 360 submits it, causing an email flood.
  • If the email specified in the form is a group mail, many people in different departments could receive hundreds of emails during the scanning process.
  • This may slow down the email server until the scan is over.
  • It is also possible to go into an infinite loop, because of weak secure coding. This kind of an issue is treated as a DoS attack.
  • (Please keep in mind that, while Acunetix 360 will not launch a DoS attack or any other malicious action, negative effects may still occur due to the existing structure of the code on the website.)
  • One simple and easy solution is to use a temporary email address during the scanning period.
  • You even can create email rules to block or reject emails coming from the scanner or forms.
  • Excluding the Send button is also another solution. This way, Acunetix 360 will avoid clicking the Submit button.
  • You can also set up a CAPTCHA on each form which will help prevent email floods by determining whether or not the user is human. This is also a good way to test if the CAPTCHA element that validates input is functioning as expected.
  • Disallowing HTTP Methods can also be a useful way of preventing requests that may negatively affect the website during a scan.

Server Slowdown or Downtime

Acunetix 360 sends requests to the target web server during scanning. Two things affect the number of requests sent: the size of the website and the security checks selected in the Scan Policy. In many cases, Acunetix 360 will send thousands of requests to the target host.

What Happens During Scanning

How to Prevent Damage

  • Acunetix 360 accelerates scanning time using a built-in Scan Policy Optimizer. You can also alter the number of requests per second from the default is 30 right up to 100. Setting it high may cause issues with the connection, or a DoS event.
  • If the target host cannot handle the amount of requests, it may run slowly or stop. The web server may stop responding, which will also affect the performance of the website.
  • Even worse, it may not provide service to visitors. If the volume of data exceeds the network's capacity, it will also result in a bottleneck. These issues can increase the scan time to several days or weeks.
  • To prevent negative web server performance, try scanning the website with a small amount of requests per second.
  • You can slow down the scan, if its performance is low. Then, when the scan is processing smoothly, you can increase the number of requests gradually.
  • Improving the server capacity allows the scanner to provide more accurate results.
  • You can run the security scan in off-peak hours by scheduling a scan.

For further information, see Scan Policy Optimizer and How Can You Improve the Scan Results?.

Overloading the Server With Requests

Log files can become overloaded if the web application determines that requests are unexpected data.

What Happens During Scanning

How to Prevent Damage

  • Scanning events and errors are logged in the web application's database or log file. Usually, these actions are recorded directly to the web server's log files too.
  • Acunetix 360 can send a huge amount of traffic in a short period of time (for example, 100 requests per second).
  • If the web application treats this as an attack, it may try to block those requests while adding them to the log files. If the necessary configurations are not added, the host server may simply run out of disk capacity.
  • In order to prevent Acunetix 360 from being considered a threat, modify the headers in the Scan Policy Editor and allowlist the IPs of the machines from which requests are generated.
  • If Acunetix 360 is running on your own machine, use to find your IP address, and allowlist it. If you are using Acunetix 360 On-Demand, allowlist the IP addresses below:


« Back to the Acunetix Support Page