⚠️ If you're thinking of an admin user when adding authentications, please read this article first: Adding an admin user when adding authentications

You can also add, view, update and delete authentications from your targets using our API. This can help if you wish to integrate vulnerability scanning as part of your CI/CD pipeline or otherwise update the authentication credentials automatically.

💡 If you have any trouble with form-based authentication, as a good first step, it might be worth trying the session cookie authentication method or using header-based authentication.

Before you start

The information below is required for our scanner to know where in your application to start scanning from, how to submit the login request, and what URL to avoid so that the scanner doesn't get logged out. A few extra tips:

http:// or https:// is required on your URLs
The Login page URL is optional but will be beneficial when our scanner tries to retrieve and update anti Cross-site Request Forgery (anti-CSRF) tokens
The Logged in pattern is optional but will help our scanner identify when it has authenticated correctly and if it needs to re-authenticate during the scan.

Adding the target

Throughout this example, we will be using vulnerablesite.intrud.es where we are hosting our test application.

⚠️ If you're unsure of where to find the info needed, we have just the article for you.

Targets > Add target
Type the target into the top box > Add target

Choosing the authentication method

Head back to Targets > All > ... > Add authentication
Click the top box: 'Form based':

Adding the authentication

Enter in the 'Details:
Entrypoint URL
The Entrypoint URL tells the scanner where it should start all of it's crawling and scanning from. In this example, we are starting our scan from the root of our application (http://vulnerablesite.intrud.es/DVWA). If you want the full application to be scanned, be sure to include a / on the end of the URL.
Login page URL
This is the URL where we can find the login page of the web application. This will be the window where the login fields can be seen. In this example, our authentication data is sent to the same URL as the login page itself (http://vulnerablesite.intrud.es/DVWA)
Login request URL
This is the URL to which your application sends the data that users have entered into the form. In this example, we want to send our authentication data to our login.php page (http://vulnerablesite.intrud.es/DVWA)
Logout URL
In our example, we specify that there is a Logout URL which we want to exclude from scanning (http://vulnerablesite.intrud.es/DVWA/logout.php), this will help us make sure that the scanner doesn't accidentally log itself out.

Note that if you have a Logout URL that includes query parameters (e.g. http://www.example.com/login?action=logout), then we would recommend always including the Logged In Pattern (optional) parameter.
Enter the form parameters
Username field and Password field
You are looking for the value of the name field for each. In this example, the username field (in the form on our target web application) is named username and the password field is named password. (These are not your user credentials for logging in).
Additional Parameters
If the authentication sends more than just the username and password parameters, these would also need to be added to the configuration by entering these into the Key/Value boxes and pressing the + Add Parameter button for any further parameters needed.

CSRF token (optional)
The scanner will attempt to use a CSRF Token from a list of the most common values (e.g. antiforgery-token, csrf-token, etc.). However, for best results, it is always best to include the exact value used in your web app, especially if you use an uncommon name for the token. In this example, we've told the scanner that we have an anti-CSRF token named user_token which the scanner needs to submit when trying to authenticate.
Add the User credentials
Username and password
Finally, you will be asked to provide the credentials for the user that you want the scanner to authenticate as.
Once you've clicked 'save and verify authentication' it's enabled and all scans will run from an authenticated perspective.

Clicking on the target will take you to the target's detail page, where you can review the authentication:

Verifying the authentication

In progress

Before you get any responses, it'll look like this:

Complete

Given how nuanced apps are, we don't presume the accuracy of authentication – instead, we show you what the scanner encountered and allow you to decide whether it has worked or not (the screenshot in particular is helpful, as you can use that to gauge if the scanner can access pages behind the login).

You could get any combination of results, here are just a few:

Managing authentication(s)

Once you've completed this information you will see the authentication appear under the Authentications tab.

To disable an authentication

Click ... > Disable:

And the modal will update to this:

To re-enable, just click the ellipsis again > Enable:

To check the status of the authentication

Click the ellipsis > Check status:

The next modal to pop up will be this one, where you can Confirm the authentication; edit the details or close the modal and disable the authentication.