In order to tailor fit Application Scanning to your web application, we offer a wide range of customization options on the Scan Profiles by using the Detectify tool or the Detectify API.
Settings in the Detectify tool
Settings can be fully customized from the Application Scanning page under the Scan Profile action. Settings are separated into 3 tabs, with an additional tab for integrations.
General settings
General settings allow you to set baseline information on the scan profile, and what kind of experimental features to allow when scanning.
What's the name of this profile? - You can use the Scan Profile name to easily identify the profile on different parts of Detectify. It also helps you to differentiate between the profiles you created for the same asset.
How often do you want to run a scan? - Running scans continuously is important to make sure that your site continues to be up to date on potential vulnerabilities. We recommend you to test your site at least once per week. Read more about scheduling Application Scanning.
Should we automatically start a scan when new security tests are added? - Enable to automatically start scans every time a new version of Application Scanning is released. Read more about scheduling Application Scanning.
How long should we keep the reports before deleting? - Detectify keeps your vulnerability information for a specific period of time after a scan runs. This is 365 days by default, and you can adjust this by setting a different number.
Opt-in for the following beta features - These features are more experimental functionality that are generally safe to use, they may have side effects on scanning results or impact on your web application. You can opt-in to any number of beta features by toggling the feature on.
Scan settings
Scan Settings allow you to set up how our core service will act during a scan.
Should we crawl subdomains? - Allowing crawling of subdomains enables the scan to also perform security testing on subdomains of the Scan Profile endpoint. This includes subdomains discovered during the scan. This setting is enabled by default. Read more about how to include or avoid subdomains in Application Scanning.
Which subdomains must we avoid? - Provide any number of subdomains that you want to avoid from being security tested. This setting is useful for avoiding some subdomains which may be covered by other Scan Profiles. You only need to specify the subdomain label(s) that should be avoided, not the full domain name. Read more about how to include or avoid subdomains in Application Scanning.
Which paths/URLs must we include? - Provide any number of root-relative paths that should be scanned. This setting is useful for ensuring security testing of pages not accessible by crawling the web application. Read more about how to include or avoid URLs and paths in Application Scanning.
Which paths/URLs must we avoid? - Provide any number of root-relative paths that should not be scanned. This setting is useful in case the web application has pages that the scanner shouldn’t tamper with. Read more about how to include or avoid URLs and paths in Application Scanning.
Should we scan common ports? - Allowing scanning of common ports enables scanning ports that are commonly open in most cases, such as 80, 443, 8080, 5432, etc. This setting is turned off by default for scan profiles created after May 1 2023. Read more about how to include or avoid ports in Application Scanning.
Which ports must we avoid? - Provide any number of ports that should not be scanned. Read more about how to include or avoid ports in Application Scanning.
Which ports must we include? - Provide any number of ports that should be scanned. Read more about how to include or avoid ports in Application Scanning.
Should we do additional crawling using Recorded Crawling? Using our Scan Behind Login plugin for Google Chrome you can record a series of actions that are replayed during the scan. All unique HTTP requests that are triggered when we re-play the recording in the scan will be saved for further security testing.
Read more about how you can use Recorded Crawling.Which predefined analytics services should we avoid? - By avoiding analytics services the scanner doesn’t affect the statistics used to track user behavior in the web application. Therefore most common analytics services are avoided by default. You can untoggle the specific service to include them.
Which User Agent/device should it identify as? - To change how your web application identifies traffic from Application Scanning you can change the device we use. Read more about how Application Scanning identifies itself to your website.
Which custom headers should always be sent? - You can add HTTP headers with name and value as means to identify network traffic from Application Scanning. The header must be prefixed with the scan profile token, or x- to make sure it won’t collide with any standard headers we use for testing (like the Host header for example).
Which custom cookies should always be sent? - You can add HTTP cookies as means to identify network traffic from Application Scanning. The cookie must have a name, a value and a domain where it applies. Optionally, the cookie can be specified as secure or HTTP-only.
How many requests per second should we send at most? - You can set the maximum number of requests per second Application Scanning can generate.
By default, we scan your site as fast as possible with the limited resources we provide for our scans. For some web applications that are sensitive this may impact the performance, or potentially cause downtime. If you notice such an effect from our scans, it is recommended you set a limitation.
Please consider that, if your web application is impacted by our scan, it can be considered as a potential vulnerability to Denial-of-Service (DoS) attacks.
The limit specified here applies on an origin basis (combination of protocol, hostname and port number).Which OWASP Top 10 categories should we test for? - By default, the scan includes tests for all OWASP Top 10 categories. With this option you can limit our security tests to not include specific 2013 or 2017 categories.
Please note that if a security test is categorized for both 2013 and 2017, both must be disabled in order to not perform the test.
Read more about OWASP categories in our blog.What AWS region do you want to receive traffic from? - You can select which region the scan should be performed, and thus the network traffic originates from. Detectify is hosted by Amazon Web Services (AWS) in multiple geographic regions, which include Ireland (eu-west-1), USA (us-east-1) and India (ap-south-1). Read more about how to run Application Scanning from different geographic regions.
Please note even if the region is set to USA or India, since our core services are located in Ireland, your web application still needs to be accessible from Ireland.
This feature is only accessible to dedicated customers, please contact your customer support representative or [email protected] for more information.
Authentication
Authentication settings allow you to scan behind login using three methods:
Recoded login - Using our Detectify Recorder Chrome extension for Google Chrome you can record a login scenario as a series of actions that are replayed at the beginning of the scan to reach the logged in state, and then perform all discovery and assessment in this state.
When uploading a recording, you can validate its behavior, which indicates how it will function during the scan.
Read the complete Recorded Login plugin documentation.Basic Auth - You can provide a username and password as basic authentication, that will be sent with all HTTP requests to your web application during the scan.
Session Cookie - You can provide a session cookie that will be sent with all HTTP requests to your web application during the scan.
The cookie must have a name, a value and a domain where it applies. Optionally, the cookie can be specified as secure or HTTP-only.
Read more about Application Scanning authentication.
Settings in the API
The Detectify API allows you to retrieve and change a subset of Application Scanning settings.
You can retrieve settings by sending a GET request to https://api.detectify.com/rest/v2/profiles/{scan profile token}/settings/.
You can change settings by sending a PUT request to https://api.detectify.com/rest/v2/profiles/{scan profile token}/settings/ with the request body holding the settings you would like to change. The update does not affect settings that are not present in the request body.
Settings that are accessible in the API:
report_lifespan_days - Detectify keeps your vulnerability information for a specific period of time after a scan runs. This is 365 days by default, and you can adjust this by setting a different number.
requests_per_second - You can set the maximum number of requests per second Application Scanning can generate.
By default, we scan your site as fast as possible with the limited resources we provide for our scans. For some web applications that are sensitive this may impact the performance, or potentially cause downtime. If you notice such an effect from our scans, it is recommended you set a limitation.
Please consider that, if your web application is impacted by our scan, it can be considered as a potential vulnerability to Denial-of-Service (DoS) attacks.
The limit specified here applies on an origin basis (combination of protocol, hostname and port number).crawl_subdomains - Allowing crawling of subdomains enables the scan to also perform security testing on subdomains of the Scan Profile endpoint. This includes subdomains discovered during the scan. This setting is enabled by default. Read more about how to include or avoid subdomains in Application Scanning.
blacklisted_subdomains - Provide any number of subdomains that you want to avoid from being security tested. This setting is useful for avoiding some subdomains which may be covered by other Scan Profiles. You only need to specify the subdomain label(s) that should be avoided, not the full domain name. Read more about how to include or avoid subdomains in Application Scanning.
whitelisted_ports - Provide any number of ports that should not be scanned. Read more about how to include or avoid ports in Application Scanning.
blacklisted_ports - Provide any number of ports that should not be scanned. Read more about how to include or avoid ports in Application Scanning.
whitelisted_paths - Provide any number of root-relative paths that should not be scanned. This setting is useful in case the web application has pages that the scanner shouldn’t tamper with. Read more about how to include or avoid URLs and paths in Application Scanning.
blacklisted_paths - Provide any number of root-relative paths that should be scanned. This setting is useful for ensuring security testing of pages not accessible by crawling the web application. Read more about how to include or avoid URLs and paths in Application Scanning.
custom_cookies - You can add HTTP cookies as means to identify network traffic from Application Scanning. The cookie must have a name (name) and a value (value). Optionally, the cookie can be specified as secure (secure) or HTTP-only (httponly).
custom_headers - You can add HTTP headers with name (name) and value (value) as means to identify network traffic from Application Scanning. The header must be prefixed with the scan profile token, or x- to make sure it won’t collide with any standard headers we use for testing (like the Host header for example).
requests_per_second - Allowing scanning of common ports enables scanning ports that are commonly open in most cases, such as 80, 443, 8080, 5432, etc. This setting is enabled by default. Read more about how to include or avoid ports in Application Scanning.
scan_region - You can select which region the scan should be performed, and thus the network traffic originates from. Detectify is hosted by Amazon Web Services (AWS) in multiple geographic regions, which include Ireland (eu-west-1), USA (us-east-1) and India (ap-south-1). Read more about how to run Application Scanning from different geographic regions.
Please note even if the region is set to USA or India, since our core services are located in Ireland, your web application still needs to be accessible from Ireland.
This feature is only accessible to dedicated customers, please contact your customer support representative or [email protected] for more information.basic_authentication - You can provide a username (username) and password (password) as basic authentication, that will be sent with all HTTP requests to your web application during the scan.
session_cookie - You can provide a session cookie that will be sent with all HTTP requests to your web application during the scan.
The cookie must have a name (name) and a value (value). Optionally, the cookie can be specified as secure (secure) or HTTP-only (httponly).
In order to manage Application Scanning settings in the API, you need to create an API key. For more information, please refer to the API documentation.
FAQ
Q: I have very different behaviors in my web application with and without login, can I test both?
A: You can create multiple scan profiles for the same web application with one having the authentication specified, and the other not. That way you will have both behaviors tested.