Authentication licenses are per FQDN and you can add as many authentications to one target as you wish.*

Methods of authentication

Scan scope

Minimising risk

SPAs

APIs

Configuring the scanner

Vulnerabilities

Results

At this time (v1.0) we cannot scan an application which requires multiple forms of authentication or prove-your-humanity checks – you can only choose one of the four methods listed in the AWAS User Guide. A possible workaround, if you need one, would be to allow Intruder scanner IP range to bypass one form of authentication.

For example:

Target: test.com

Entrypoint: test.com

Login request URL: blue.com/login

Currently (v1.0) the scanner will only authenticate to URLs which are within the scope to be scanned. For example, if the entry point is test.com/app, the logout URL would need to be something like test.com/app/logout. If you use a separate authentication domain you can potentially workaround this constraint by setting a long-lived session token (~24 hours) on your target application and using the session-based authentication method.

For example:
Target: test.com

Entrypoint: test.com

Login request: test.com/login➡️ Redirect: blue.com/dashboard

The scanner can't handle this, so the solution would be to add blue.com as the target and set blue.com as the Entrypoint and you'll need a session token, because you aren't authenticating via test.com/login.

No. Currently (v1.0) it is not possible for our scanner to bypass multi-factor authentication checks. You will need to authorise our Intruder scanner IP range or the user account that you specify in your Authentication to bypass the checks. An alternative workaround is to use a long-lived session token (~24 hours) and use the session-based authentication method.

No, currently (v1.0) our scanner will not be able to follow specific SSO authentication workflows (including AWS Cognito/SSO, Google Identity, Microsoft AzureAD, Okta, OneLogin, Auth0, JumpCloud etc). Instead, you will need to implement one of the following so that the scanner can bypass SSO:

Unfortunately we don’t support applications that have a JSON-formatted login request. Instead, we would recommend using one of the following, if possible:

No. At this time (v1.0) our scans are scoped to the target on which you add your authentication. That means that if you add an authentication to portal.intruder.io the scan will not crawl to pages on internal-api.intruder.io. This can cause issues for some single-page applications which use multiple endpoints; a possible workaround would be adding an authentication to each domain/hostname that you wish to be scanned.

No. Our Authenticated scans will crawl/spider pages within an application, and will follow any link it discovers. However, the scanner will only include URLs which are on the target to which Authentication is assigned. So, if you try and scan portal.intruder.io and the scanner identifies a link to internal-api.intruder.io it will not include that link, as it points to a different target. If both portal.intruder.io and internal-api.intruder.io have Authentication Licenses assigned to them, they will be scanned separately.

At this point (v1.0) the scanner will only exclude the URL of the logout path that you specify within your authentication. All other URLs associated with the target that your Authentication is on will be included in the scan.

That said, your entrypoint URL determines where the scan starts. For example, https://vulnerablesite.intrude.es/login would mean that the scan starts at the login page, which would restrict the scanner from looking at the frontend. If that's what you want, then perfect, if not, it might make sense to set https://vulnerablesite.intrude.es/login as the login URL and https://vulnerablesite.intrude.es as the entrypoint.

*Yes, you can specify an Entrypoint when you configure your Authentication.
If your Entrypoint includes a path such as http://portal.intruder.io/users/ then the scan will only include pages and directories under /users/.

Currently (v1.0) you cannot disable authentications. When you start a scan against a target with authentications assigned to it, all authentications will be included in the scan.

In short, the scanner can run safely on many production websites, but it's usually best to stick to staging to reduce the chance of damage.

We'd advise against adding admin credentials, as explained in this article.

The scanner can handle simple SPAs, but the more complex or abnormal the behaviour, the more likely it is that the coverage will be compromised.

To understand the correlation between complexity and coverage, it might help to understand how the scanner handles SPAs. It starts by fetching the application and running it within a headless browser; it then it manipulates the Document Object Model (DOM) and attempts to follow links it finds, recording a list of paths and parameters for further analysis as it goes. For more information, head to our SPA help article.

Yes, we do handle JWT's. To set this up, you'll will need to login to your application, record the JWT and then set the JWT as the authentication (usually this is as header-based authentication using the Authorisation: Bearer <token> header). We'll then receive authenticated responses from the backend API.

It's important that the token lasts slightly longer than it takes for the scan to complete. We typically recommend 24 hours, though we'd expect most scans to complete much sooner than this.

However, we do not currently (v1.0) support the configuration of Local Storage within our headless browser which means we may not be able to crawl SPAs which use Local Storage to present an authenticated page.

Yes, but currently we don't allow users to upload a list of endpoints/paths or API schemas. As such, we can only identify endpoints/paths to scan based on what we discover in web applications. So, if your API supports a web application we will be able to scan it by crawling/spidering the web application. However, we cannot yet (v1.0) support full coverage of APIs.

If your OpenAPI/Swagger schema is accessible within the scope of the scan our scanner will parse the schema and use it to build a list of endpoints which will be included in testing – as long as those endpoints are within the scope of the scan.

Yes, but currently (v1.0) the same rules apply to those in the section above, your GraphQL definition must be reachable from the entrypoint specified within your Authentication configuration.

Currently, configurations are limited to what is outlined in the AWAS user guide. If you don't see what you're looking for, it's always worth dropping our support team a message – understanding your motivations and expectations helps us build the tool that fulfils your needs.

Currently (v1.0) you cannot limit the number of requests per second that our scanner sends to your application.

Whilst it is possible, we wouldn't necessarily recommend it. Instead, we'd recommend disabling all but one, so you're only scanning one authentication at a time.

To do this, head to your target's detail page:

Scroll down to 'Authentications', click ... and hit 'Disable':

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

The best way to check would be to have a look through any logs on your servers. There isn't one standard response to look for (as it really depends on what you log) but hopefully one of the following will help:

Yes! if you click on the relevant scan from the Scans Page, and click the "Scanned Authenticated URLs" tab, you can view a list of URLs that the Authenticated Web-App Scanner has been able to crawl.