Minimising Risk
We'd advise against adding admin credentials, as explained in this article.
Whilst the scanner can run safely on many production websites, it's usually best to stick to staging to reduce the chance of damage.
My application requires multiple forms of authentication (e.g. reCAPTCHA)
At this time (v1.2) we cannot scan an application that requires multiple forms of authentication or prove-your-humanity checks; you must choose one of the methods listed in our Quick Guide to Authenticated Web Application Scanning.
If your app uses two forms of authentication, you could set up one of the methods outlined in the link above and add our scanner IP range to the relevant allowlist to bypass the other.
Authentication is handled by a different domain
For example:
Target |
|
Entrypoint |
|
Login Request URL |
|
Currently (v1.2) the scanner will only authenticate to URLs 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.
One workaround for this constraint is to set a long-lived session token (~24 hours) on your target application and use the session cookie authentication method.
Another option for apps using this authentication flow is to add a Recorded Login authentication method to provide the scanner with the steps needed to log in
After authenticating, there is a login redirect
For example:
Target |
|
Entrypoint |
|
Login Request URL |
|
There are two options for this:
You can try the recorded login authentication method.
or
Add your preferred authentication method to
test.com, makingtest.comthe entrypoint.
andAdd
blue.comas a separate, additional external target; and using session cookie authentication, addblue.com/dashboardas the entrypoint.
My application uses Multi-Factor Authentication (MFA/2FA)
Currently (v1.2) it is not possible for our scanner to bypass multi-factor authentication checks.
There are a few options for this:
You can try the recorded login authentication method.
or
Use a long-lived session token (~24 hours) the session cookie authentication method.
or
Allow the Intruder scanner IP range to bypass one (or both) forms of MFA / allow the user account specified in your Authentication to bypass MFA
My application uses Single-Sign-On (SSO)
Currently (v1.2) our scanner isn't able to follow specific SSO authentication workflows (including AWS Cognito/SSO, Google Identity, Microsoft AzureAD, Okta, OneLogin, Auth0, JumpCloud etc.).
The workaround for this would be to either:
(if supported) Use one of the following alternative authentication methods:
or
Add an API to your target and provide an Authorization header as an authentication method.
Within this authentication, you would use a JSON Web Token (JWT) with a 24-hour validity period
Authentication uses a JSON-based form
Unfortunately, we don’t support applications that have a JSON-formatted login request.
The workaround for this would be to use one of the following alternative authentication methods:
Authentication uses JWT's (JSON Web Tokens)
We do handle JWT's, however we don't currently support (in v1.2) the configuration of Local Storage within our headless browser which means we may not be able to crawl SPAs that use Local Storage to present an authenticated page.
The workaround for this constraint would be to add the JWT within a Header Authentication method. To do this:
Log in to your application
Record the JWT
Add this to your target using the Header-Based Authentication method using the
Authorisation: Bearer <token>header (this will mean that we'll receive authenticated responses from the backend API)
The token needs to last for longer than the scan takes to complete - we typically recommend around 24 hours.
I have a short authentication token validity period
If you have set up an authentication on one of your targets but the authentication values (e.g. the session cookie token or the header value) validity period is quite short, then this means you will need to update this value on the Target Detail page every time before you kick off a scan on the target.
To make this as quick and easy as possible, we would recommend leveraging the capabilities to add, view, update and delete authentications from your targets using our API.
This means that you can automatically update the values in the Intruder portal without having to manually go and update them against each target.
My application uses passwordless One Time Passcode (OTP) authentication
At this time (v1.2) we are not able to retrieve the OTP sent to your email/phone number. For this reason, we would need you to use a workaround so that we can authenticate to the application without requiring the OTP code.
The workaround for this would be to use one of the following alternative authentication methods: