All Collections
Web-application scanning
Choosing the right license for scanning your web application
Choosing the right license for scanning your web application

Our licenses offer different coverage, make sure you're using the right one for you and your web-app

Naomi Purvis avatar
Written by Naomi Purvis
Updated over a week ago

All plans – by default – include Infrastructure Licenses that scan internet-facing targets from an unauthenticated perspective. This is useful for finding security misconfigurations or known vulnerabilities that a hacker could exploit from the internet – be it manually, or via an automated tool such as 'Autopwn'.

All users have the option to add an Application license to their subscription. This license features enhanced DAST scanning, which attempts to identify vulnerabilities in the same way an attacker would by updating its approach dynamically whilst testing. It also permits the scanning of authenticated pages and API schemas. For a more granular look at what's covered, please see below:

Scanning web-apps with an Infrastructure license

👉 If you were to specify the web-app as a target (e.g . example.io) and kick off a scan:

We'll check unauthenticated pages for some common off-the-shelf web-app issues and perform all the usual infrastructure checks, including checks against the web server hosting the web-app, these could cover:

  • Unintentionally exposed systems

  • Information Leakage

  • Encryption weaknesses

  • Misconfigurations & common mistakes

  • Remote vulnerable Software and missing patches

Scanning web-apps with an Application license

👉 If you are to specify the web-app as a target (e.g . example.io) either by adding as a web application target or adding an authentication to an existing infrastructure target (including placeholder authentication for unauthenticated web-apps) and kick off a scan:

We'll perform all the usual infrastructure checks, including checks against the web server hosting the web-app (as highlighted above):

  • Unintentionally exposed systems

  • Information Leakage

  • Encryption weaknesses

  • Misconfigurations & common mistakes

  • Remote vulnerable Software and missing patches

In addition to that, we'll check unauthenticated and authenticated pages for common vulnerability categories, as well as weaknesses in custom software (including zero days), this could include:

  • OS command injection

  • Enhanced Cross-site scripting (XSS); persistent/stored, reflected and DOM-based XSS

  • Enhanced SQL injection; against multiple types of databases

  • NoSQL injection; specifically against MongoDB

  • LDAP injection

  • XPath injection

  • Server-side includes

  • Server-side code injection

  • Java serialisation weaknesses

  • Buffer and integer overflows


💰 You can add as many authentications to a target as you wish and it will only consume one Application license, which is especially helpful if:

  • Your application has different user types (and you want to scan from each POV)

  • Your application has different permission levels (and you want to scan from each POV)

  • Your target (IP address or domain) hosts multiple applications (and you want to scan all of them).

⚠️ Please note: The "entry point" of the application must correlate with the target you're adding the authentication to. Eg. If you're adding authentication to target: portal.intruder.io the scanner will not crawl to pages on internal-api.intruder.io. For more info, have a read of our FAQs.


Benefits of scanning the authenticated pages of your web-app

Some of the most critical functionality in an application exists behind the login page: the ability to add data to your account; edit data; delete data; upload files and interact with other users. As a result, a large percentage of the attack surface of an application can exist on the authenticated pages and if you’re not scanning them, you’re unaware of the potential risk they pose – which could leave you, your application and the end-user exposed if exploited.

By reducing the likelihood of a compromise, you reduce the associated costs, including:

  • Downtime of your application (either from a denial of service/ransomware impact or from the incident response process)

  • Loss of business from customers/users that are spooked

  • Impact to reputation

  • Financial and time cost of going through an incident response process

  • Financial impact from regulators/Information Commissioner Office

  • Cyber insurance premiums

What type of attacks can I prevent by scanning the authenticated layers of my web-app?

  • Malicious authenticated users, especially if your app allows anyone on the internet to sign up and login to your application.

  • Initial access for large compromises. An example might be successfully identifying an OS command injection vulnerability and using it as a beach head to launch further attacks

  • Information disclosure/ransomware. This describes an attacker who can successfully extract critical business information from a backend database so they can ransom the data, post it on forums and have others bid for it.

  • Proxy attacks are when an attacker can find a vulnerability that when exploited, impacts other users or someone who accesses a link to the application, such as cross-site scripting (XSS) or cross-site request forgery (CSRF). The attacker can then exploit third-parties using the trust associated with the compromised web application/domain

How often should I use AWAS?

This will depend on your organisation, your risk tolerance, the type of applications that you have configured, and the rate at which those applications are changing.

  • If you’re actively releasing updates for an application, then you should be scanning every time there is a change to logic/workflow within their application.

  • If the application doesn’t change frequently then scanning it once or twice a month should be enough to ensure that the results haven’t gone stale and there hasn’t been any drift.

Ultimately, the license allows you to scan the application whenever you like, all that happens is that the 30-day license consumption is reset – which is a very small price to pay for peace of mind.


Are there any vulnerabilities that aren't covered?

Yes, Owing to a technical limitation (which we are working to resolve) we currently (v1.0) cannot detect out-of-band callbacks.

Did this answer your question?