Running Application Scanning

Application Scanning performs an in-depth exploration and security assessment of your custom-built web application. Below we break down  the process of what to expect from our scans.

Starting scans

Scans can be started via the Detectify tool (via the dashboard, assets, or scan profile page) and the Detectify API. In case there is a high volume of newly started scans, it may take a few minutes before we start exploring the web application.

In order to keep your website continuously secure, we recommend scheduling your Application Scan on a weekly basis at the minimum. 

If we’re unable to reach the scan profile endpoint via HTTP/HTTPS protocols (on ports 80 and 443) due to firewall or other network issues, we will notify you that the scan failed to resolve. You should take a look at how to allow Detectify to access your site.

Exploration

We explore your application on multiple levels. First, we gather information about the application in general such as DNS records and TLS/SSL certificates.

Thereafter, we crawl your web application to explore various web content within the scope of your scan profile. The scope of the scan profile is the endpoint for which the profile was created. 

  • If you have “crawl subdomains” enabled in the settings, we will crawl the endpoint specified in the scan profile as well as all its subdomains. Take a look at which subdomains we look for.

  • If “scan common ports” is enabled in settings, we will also crawl a range of ports if they are found to be open. Take a look at which ports we scan


For each hostname and port, we check for both HTTP and HTTPS protocols, and crawl the ones that the application supports. We also gather resources (e.g. JavaScript, images) from both inside and outside the endpoint in order to fully render the web content. By default, we avoid resources that may cause side effects, such as analytics services.

During crawling for each origin (protocol, hostname and port bundle) we start from the application root (/), and a variety of other potential starting points (e.g. /admin, /wp-content). We also use external information sources to gather historical data about your web application, such as the Internet Archive. As a web application may have a number of similar web pages that are vulnerable to the same attacks, we look for unique web pages. We use a heuristic page filtering mechanism, and the content we deem unique is saved for further assessment, while similar content is filtered as duplicate.

During the exploration we also fingerprint technologies that we identify. We will, for example, resolve the hosting provider, the operating system, JavaScript libraries and so forth. This information both helps you identify which software you publicly expose, and helps us determine the kind of assessment to perform against your application.

Assessment

We perform both static analysis of the explored content and active exploitation of potential vulnerabilities. We report each vulnerability in real-time, so you can get instant updates via email, integrations, or by visiting vulnerabilities.

We gather the crawled information, and analyse the content in various ways to discover common mistakes such as invalid TLS certificates, incorrectly configured login forms, error messages and database backups. We also scan for malware using VirusTotal and its antivirus solutions.

During exploitation, we send various payloads towards your web application to find unintended behavior that may be used in a malicious manner. This includes a wide range of tests such as cross-site scriptingSQL injectionpath traversal, among others. While we try to minimize the impact with our tests – as we emulate potentially harmful abuse of some functionality – these tests can be easily picked up as malicious attacks by your web application’s defenses (such as firewalls). If this causes an unwanted effect in your application, you can adjust the settings, for example avoid spamming of contact forms.

Assessment is greatly impacted by the technologies we discover during the scan, as we don’t exploit vulnerabilities that are not relevant to your application. In general, our assessment is targeted towards specific aspects of the application (e.g. login form), and not towards the entire application. While we have seen examples where the web application was affected by our scanners due to the large number and frequency of requests, we don’t emulate denial-of-service (DoS) attacks towards the application. This can happen when the application's resources are quite limited.

Scan completion
Once the scan is done with running the relevant tests, we alert you of the scan’s completion via e-mail or integrations. Information on scan is also accessible in the activity log.

You are able to stop (abort) the scan any time when it’s running both via the Detectify tool (via the dashboard, assets, or scan profile page) and the Detectify API. Please allow a few minutes for us to halt the scan completely. In case of stopped scans, the discovered vulnerabilities will still be available.

Scanning time

The runtime of Application Scanning depends on a lot of factors, and therefore can be anywhere from 15 minutes up to 48 hours. 

These factors include scanning settings (e.g. rate limiting), the size of the web application (e.g. number of different pages), responsiveness of the application (e.g. time to load pages and HTTP response time), and the different technologies used, as it impacts the number of security tests we run.

We have set limits on various aspects of the scan. For example, we never crawl more than 50,000 web pages, or crawl longer than 8 hours. Thus with a longer scan the results may be less accurate. See how to set up your account for the best possible results to get to know more about optimal configuration of Application Scanning.

Q&A

Q: What impact should I expect on my web application?

A: Depending on the size of your web application we may send thousands, or even millions of HTTP requests during the scan, which can be of various methods (e.g. GET, HEAD, POST), and the rate of these requests may vary from time to time. If you’d like to make sure we don’t send too many requests over a short period, you can set request rate limits in the settings.

Q: Can I stop scans immediately if needed?

A: You can stop the scan at any time. Please allow up to a few minutes time for the scan to halt all requests towards your application.

Q: The scan “ended forcefully”. What went wrong?

A: We’re very sorry about that. In most cases the sheer size of the application causes the scan to malfunction, especially if it happens several hours into the scan. We recommend you to decrease the scope of the scan. This can be done for example by disabling “crawl subdomains”, and avoiding some paths in the application. See how to set up your account for the best possible results.