Contact Support


Scanning Production Environments

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

  • Netsparker acts as a search engine bot to create a sitemap of the target website in the crawling stage. In the attacking stage, Netsparker sends payloads in order to identify, for example, SQL Injection and Cross-site Scripting in the target website.
  • Netsparker 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 emails 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, Netsparker 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

Netsparker 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

What You Can Do

  • While attacking the target web application, Netsparker'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 Netsparker could also be exploited by a malicious visitor.

  • When you launch scans on test websites, during the crawling phase, Netsparker clicks all elements on the discovered page. 
  • If you are launching a scan in a live production 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, Netsparker would click on it during scanning. 
  • Naturally, this could damage your website. You can prevent Netsparker from testing delete.php by excluding it from the scan using our Exclude URLs with RegEx option (see Configuring the Scan).
  • 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

What You Can Do

  • Netsparker submits application forms or simple contact forms multiple times to check for vulnerabilities. The form generates an email each time Netsparker 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 Netsparker 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, Netsparker 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

Netsparker 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, Netsparker will send thousands of requests to the target host.

What Happens During Scanning

What You Can Do

  • Netsparker 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.

For further information, see Scan Policy Optimizer and How Fast is Your Web Vulnerability Scanner?.

Overloading the Server With Requests

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

What Happens During Scanning

What You Can Do

  • 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.
  • Netsparker 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 Netsparker from being considered a threat, modify the headers in the Scan Policy Editor and whitelist the IPs of the machines from which requests are generated. 
  • If Netsparker is running on your own machine, use to find your IP address, and whitelist it. If you are using Netsparker Enterprise On-Demand, whitelist the IP addresses below:


  • Netsparker allows you to choose the server location for GDPR compliance. If you want to use the EU instance, which is physically located in EU (, whitelist the IP addresses below:




Highly accurate, fast & easy-to-use Web Application Security Scanner

Get a demo