doc/user/application_security/dast/browser/configuration/authentication.md
For complete coverage, the DAST analyzer must authenticate with the application being tested. This requires configuring the authentication credentials and authentication method in the DAST CI/CD job.
DAST requires authentication to:
The DAST job authenticates itself to the application, most commonly by filling in and submitting a login form on a browser. After the form is submitted, the DAST job confirms that authentication was successful. If authentication was successful, the DAST job continues and also saves the credentials for reuse when crawling the target application. If not, the DAST job stops.
Authentication methods supported by DAST include:
When choosing authentication credentials:
The following diagram illustrates the usage of authentication variables at different stages of authentication:
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Authentication variables
accDescr: A sequence diagram showing authentication variables at different stages of authentication.
participant DAST
participant Browser
participant Target
Note over DAST,Target: Initialization
DAST->>Browser: Initialize browser with proxy
DAST->>Browser: Navigate to DAST_AUTH_URL
Browser->>Target: Load initial page
Target-->>Browser: Return page content (may not contain login form)
Note over DAST,Target: Process before-login actions
DAST->>Browser: Click elements specified in DAST_AUTH_BEFORE_LOGIN_ACTIONS
Browser->>Target: Send click actions
Target-->>Browser: Render login form (modal/page)
Note over DAST,Target: Authentication
DAST->>Browser: Fill DAST_AUTH_USERNAME & DAST_AUTH_PASSWORD
DAST->>Browser: Click "submit"
Browser->>Target: Submit form
Target-->>Browser: Process authentication
Target-->>Browser: Set auth tokens
Note over DAST,Target: Process after-login actions (if specified)
DAST->>Browser: Execute DAST_AUTH_AFTER_LOGIN_ACTIONS
Browser->>Target: Actions after login but before login verification
Note over DAST,Target: Verification
DAST->>Browser: Check URL matches DAST_AUTH_SUCCESS_IF_AT_URL (if configured)
DAST->>Browser: Check element exists DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND (if configured)
DAST->>Browser: Check login form absent DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM (default is true)
[!note] You should periodically confirming that the analyzer's authentication is still working, as this tends to break over time due to changes to the application.
To run a DAST authenticated scan:
{{< history >}}
{{< /history >}}
For a list of DAST Authentication CI/CD variables, see Authentication variables.
The DAST CI/CD variable table is generated by the Rake task bundle exec rake gitlab:dast_variables:compile_docs. It uses variable metadata defined in lib/gitlab/security/dast_variables.rb.
The target website, defined using the CI/CD variable DAST_TARGET_URL, is the URL DAST uses to begin crawling your application.
For best crawl results on an authenticated scan, the target website should be a URL accessible only after the user is authenticated. Often, this is the URL of the page the user lands on after they're logged in.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com/dashboard/welcome"
DAST_AUTH_URL: "https://example.com/login"
To use an HTTP authentication scheme such as Basic Authentication you can set the DAST_AUTH_TYPE value to basic-digest.
Other schemes such as Negotiate or NTLM may work but aren't officially supported due to current lack of automated test coverage.
Configuration requires the CI/CD variables DAST_AUTH_TYPE, DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD to be defined for the DAST job. If you don't have a unique login URL, set DAST_AUTH_URL to the same URL as DAST_TARGET_URL.
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_TYPE: "basic-digest"
DAST_AUTH_URL: "https://example.com"
Do not define DAST_AUTH_USERNAME and DAST_AUTH_PASSWORD in the YAML job definition file as this could present a security risk. Instead, create them as masked CI/CD variables using the GitLab UI.
See Custom CI/CD variables for more information.
A single-step login form has all login form elements on a single page.
Configuration requires the CI/CD variables DAST_AUTH_URL, DAST_AUTH_USERNAME, DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD, DAST_AUTH_PASSWORD_FIELD, and DAST_AUTH_SUBMIT_FIELD to be defined for the DAST job.
You should set up the URL and selectors of fields in the job definition YAML, for example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_URL: "https://example.com/login"
DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
Do not define DAST_AUTH_USERNAME and DAST_AUTH_PASSWORD in the YAML job definition file as this could present a security risk. Instead, create them as masked CI/CD variables using the GitLab UI.
See Custom CI/CD variables for more information.
A multi-step login form has two pages. The first page has a form with the username and a next submit button. If the username is valid, a second form on the subsequent page has the password and the form submit button.
Configuration requires the CI/CD variables to be defined for the DAST job:
DAST_AUTH_URLDAST_AUTH_USERNAMEDAST_AUTH_USERNAME_FIELDDAST_AUTH_FIRST_SUBMIT_FIELDDAST_AUTH_PASSWORDDAST_AUTH_PASSWORD_FIELDDAST_AUTH_SUBMIT_FIELD.You should set up the URL and selectors of fields in the job definition YAML, for example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_URL: "https://example.com/login"
DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
DAST_AUTH_FIRST_SUBMIT_FIELD: "css:button[name=next]"
DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
Do not define DAST_AUTH_USERNAME and DAST_AUTH_PASSWORD in the YAML job definition file as this could present a security risk. Instead, create them as masked CI/CD variables using the GitLab UI.
See Custom CI/CD variables for more information.
Configuration for TOTP requires these CI/CD variables to be defined for the DAST job:
DAST_AUTH_OTP_FIELDDAST_AUTH_OTP_KEYIf the TOTP token is submitted in its own form after the password has been submitted, you must also define this variable:
DAST_AUTH_OTP_SUBMIT_FIELDThe _FIELD selector variables can be defined in the job definition YAML, for example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_URL: "https://example.com/login"
DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"
DAST_AUTH_OTP_FIELD: "name:otp"
DAST_AUTH_OTP_SUBMIT_FIELD: "css:input[type=submit]"
Do not define DAST_AUTH_OTP_KEY in the YAML job definition file as this could present a security risk. Instead, create it as a masked CI/CD variable using the GitLab UI.
See Custom CI/CD variables for more information.
If a user can sign in to an application, then in most cases, DAST is also able to sign in. Even when an application uses Single Sign-on. Applications using SSO solutions should configure DAST authentication using the single-step or multi-step login form configuration guides.
DAST supports authentication processes where a user is redirected to an external Identity Provider's site to sign in. Check the known issues of DAST authentication to determine if your SSO authentication process is supported.
Windows integrated authentication (Kerberos) is a common authentication mechanism for line of business (LOB) applications hosted inside a Windows domain. It provides promptless authentication using the user's computer login.
To configure this form of authentication perform the following steps:
dast job definition in your .gitlab-ci.yml file.krb5.conf file using the information collected.Collect the following information with assistance from your IT/Operations department:
EXAMPLE.COM)Create the krb5.conf file:
[libdefaults]
# Realm is another name for domain name
default_realm = EXAMPLE.COM
# These settings are not needed for Windows Domains
# they support other Kerberos implementations
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
rdns = false
fcc-mit-ticketflags = true
[realms]
EXAMPLE.COM = {
# Domain controller or KDC
kdc = kdc.example.com
# Domain controller or admin server
admin_server = kdc.example.com
}
[domain_realm]
# Mapping DNS domains to realms/Windows domain
# DNS domains provided by DAST_AUTH_NEGOTIATE_DELEGATION
# should also be represented here (but without the wildcard)
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
This configuration makes use of the DAST_AUTH_NEGOTIATE_DELEGATION variable.
This variable sets the following Chromium policies needed to allow integrated authentication:
The settings for this variable are the DNS domains associated with your Windows domain or Kerberos realm. You should provide them:
For our example the Windows domain is EXAMPLE.COM and the DNS domain is example.com.
This gives us a value of *.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM for DAST_AUTH_NEGOTIATE_DELEGATION.
Pull it all together into a job definition:
# This job will extend the dast job defined in
# the DAST template which must also be included.
dast:
image:
name: "$SECURE_ANALYZERS_PREFIX/dast:$DAST_VERSION$DAST_IMAGE_SUFFIX"
docker:
user: root
variables:
DAST_TARGET_URL: https://target.example.com
DAST_AUTH_URL: https://target.example.com
DAST_AUTH_TYPE: basic-digest
DAST_AUTH_NEGOTIATE_DELEGATION: '*.example.com,example.com,*.EXAMPLE.COM,EXAMPLE.COM'
# Not shown -- DAST_AUTH_USERNAME, DAST_AUTH_PASSWORD set via Settings -> CI -> Variables
before_script:
- KRB5_CONF='
[libdefaults]
default_realm = EXAMPLE.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
rdns = false
fcc-mit-ticketflags = true
[realms]
EXAMPLE.COM = {
kdc = ad1.example.com
admin_server = ad1.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
'
- cat "$KRB5_CONF" > /etc/krb5.conf
- echo '$DAST_AUTH_PASSWORD' | kinit $DAST_AUTH_USERNAME
- klist
Expected output:
The job console output contains the output from the before script. It will look similar to the following if authentication was successful. The job should fail if it was unsuccessful without running a scan.
Password for [email protected]:
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]
Valid starting Expires Service principal
11/11/2024 21:50:50 11/12/2024 07:50:50 krbtgt/[email protected]
renew until 11/12/2024 21:50:50
The DAST scanner will also output the following, indicating success:
2024-11-08T17:03:09.226 INF AUTH attempting to authenticate find_auth_fields="basic-digest"
2024-11-08T17:03:09.226 INF AUTH loading login page LoginURL="https://target.example.com"
2024-11-08T17:03:10.619 INF AUTH verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (auto-detected)"
2024-11-08T17:03:10.619 INF AUTH requirement is satisfied, HTTP login request returned status code 200 want="HTTP status code < 400" url="https://target.example.com/"
2024-11-08T17:03:10.623 INF AUTH requirement is satisfied, did not detect a login form want="no login form found (auto-detected)"
2024-11-08T17:03:10.623 INF AUTH authentication token cookies names=""
2024-11-08T17:03:10.623 INF AUTH authentication token storage events keys=""
2024-11-08T17:03:10.623 INF AUTH requirement is satisfied, basic authentication detected want="has authentication token"
2024-11-08T17:03:11.230 INF AUTH login attempt succeeded
Define DAST_AUTH_BEFORE_LOGIN_ACTIONS to provide a path of elements to click on from the DAST_AUTH_URL so that DAST can access the
login form. This method is suitable for applications that show the login form in a pop-up (modal) window or when the login form does not
have a unique URL.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_URL: "https://example.com/login"
DAST_AUTH_BEFORE_LOGIN_ACTIONS: "css:.navigation-menu,css:.login-menu-item"
Define DAST_AUTH_AFTER_LOGIN_ACTIONS to provide a sequence of actions to perform
after submitting the sign-in form, but before verification, when authentication details are recorded.
This can be used to proceed past a "keep me signed in" dialog.
| Action | Format |
|---|---|
| Click on an element | click(on=<selector>) |
| Select an option from a dropdown | select(option=<selector>) |
Actions are comma-separated. For information about selectors, see finding an element's selector.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_URL: "https://example.com/login"
DAST_AUTH_AFTER_LOGIN_ACTIONS: "select(option=id:accept-yes),click(on=id:continue-button)"
If DAST crawls the logout URL while running an authenticated scan, the user is logged out, resulting in the remainder of the scan being unauthenticated.
It is therefore recommended to exclude logout URLs using the CI/CD variable DAST_SCOPE_EXCLUDE_URLS. DAST isn't accessing any excluded URLs, ensuring the user remains logged in.
Provided URLs can be either absolute URLs, or regular expressions of URL paths relative to the base path of the DAST_TARGET_URL. For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com/welcome/home"
DAST_SCOPE_EXCLUDE_URLS: "https://example.com/logout,/user/.*/logout"
Selectors are used by CI/CD variables to specify the location of an element displayed on a page in a browser.
Selectors have the format type:search string. DAST searches for the selector using the search string based on the type.
| Selector type | Example | Description |
|---|---|---|
css | css:.password-field | Searches for a HTML element having the supplied CSS selector. Selectors should be as specific as possible for performance reasons. |
id | id:element | Searches for an HTML element with the provided element ID. |
name | name:element | Searches for an HTML element with the provided element name. |
xpath | xpath://input[@id="my-button"]/a | Searches for a HTML element with the provided XPath. XPath searches are expected to be less performant than other searches. |
Chrome DevTools element selector tool is an effective way to find a selector.
Elements tab in Chrome DevTools with the keyboard shortcut
<kbd>Command</kbd>+<kbd>Shift</kbd>+<kbd>C</kbd> in macOS or
<kbd>Control</kbd>+<kbd>Shift</kbd>+<kbd>C</kbd> in Windows or Linux.Select an element in the page to select it tool.
In this example, the id="user_login" appears to be a good candidate. You can use this as a selector as the DAST username field by setting
DAST_AUTH_USERNAME_FIELD: "id:user_login".
Judicious choice of selector leads to a scan that is resilient to the application changing.
In order of preference, you should choose as selectors:
id fields. These fields generally unique on a page, and rarely change.name fields. These fields generally unique on a page, and rarely change.class values specific to the field, such as the selector "css:.username" for the username class on the username field."css:[data-username]" when the data-username field has any value on the username field.class hierarchy values, such as the selector "css:.login-form .username" when there are multiple elements with class username but only one nested inside the element with the class login-form.When using selectors to locate specific fields you should avoid searching on:
id, name, attribute, class or value that is dynamically generated.column-10 and dark-grey.css:* and xpath://*.After DAST has submitted the login form, a verification process takes place to determine if authentication succeeded. The scan halts with an error if authentication is unsuccessful.
Following the submission of the login form, authentication is determined to be unsuccessful when:
400 or 500 series status code.Verification checks run checks on the state of the browser once authentication is complete to determine further if authentication succeeded.
DAST tests for the absence of a login form if no verification checks are configured.
Define DAST_AUTH_SUCCESS_IF_AT_URL as the URL displayed in the browser tab after the login form is successfully submitted.
DAST compares the verification URL to the URL in the browser after authentication. If they are not the same, authentication is unsuccessful.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_SUCCESS_IF_AT_URL: "https://example.com/user/welcome"
Define DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND as a selector that finds one or many elements on the page
displayed after the login form is successfully submitted. If no element is found, authentication is unsuccessful.
Searching for the selector on the page displayed when login fails should return no elements.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND: "css:.welcome-user"
Define DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM as "true" to indicate that DAST should search for the login form on the
page displayed after the login form is successfully submitted. If a login form is still present after logging in, authentication is unsuccessful.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_SUCCESS_IF_NO_LOGIN_FORM: "true"
DAST records authentication tokens set during the authentication process. Authentication tokens are loaded into new browsers when DAST opens them so the user can remain logged in throughout the scan.
To record tokens, DAST takes a snapshot of cookies, local storage, and session storage values set by the application before the authentication process. DAST does the same after authentication and uses the difference to determine which were created by the authentication process.
DAST considers cookies, local storage and session storage values set with sufficiently "random" values to be authentication tokens.
For example, sessionID=HVxzpS8GzMlPAc2e39uyIVzwACIuGe0H would be viewed as an authentication token, while ab_testing_group=A1 would not.
The CI/CD variable DAST_AUTH_COOKIE_NAMES can be used to specify the names of authentication cookies and bypass the randomness check used by DAST.
Not only can this make the authentication process more robust, but it can also increase vulnerability check accuracy for checks that
inspect authentication tokens.
For example:
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_COOKIE_NAMES: "sessionID,refreshToken"
The logs provide insight into what DAST is doing and expecting during the authentication process. For more detailed information, configure the authentication report.
For more information about particular error messages or situations see known problems.
The browser-based analyzer is used to authenticate the user. For advanced troubleshooting, see browser-based troubleshooting.
The console output of the DAST CI/CD job shows information about the authentication process using the AUTH log module.
For example, the following log shows failed authentication for a multi-step login form.
Authentication failed because a home page should be displayed after login. Instead, the login form was still present.
2022-11-16T13:43:02.000 INF AUTH attempting to authenticate
2022-11-16T13:43:02.000 INF AUTH loading login page LoginURL=https://example.com/login
2022-11-16T13:43:10.000 INF AUTH multi-step authentication detected
2022-11-16T13:43:15.000 INF AUTH verifying if user submit was successful true_when="HTTP status code < 400"
2022-11-16T13:43:15.000 INF AUTH requirement is satisfied, no login HTTP message detected want="HTTP status code < 400"
2022-11-16T13:43:20.000 INF AUTH verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-24T14:43:20.000 INF AUTH requirement is satisfied, HTTP login request returned status code 200 url=https://example.com/user/login?error=invalid%20credentials want="HTTP status code < 400"
2022-11-16T13:43:21.000 INF AUTH requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[id=email] or css:[id=password] or css:[id=submit])"
2022-11-16T13:43:21.000 INF AUTH login attempt failed error="authentication failed: failed to authenticate user"
[!warning] The authentication report can contain sensitive information such as the credentials used to perform the login.
An authentication report can be saved as a CI/CD job artifact to assist with understanding the cause of an authentication failure.
The report contains steps performed during the login process, HTTP requests and responses, the Document Object Model (DOM) and screenshots.
An example configuration where the authentication debug report is exported may look like the following:
dast:
variables:
DAST_TARGET_URL: "https://example.com"
DAST_AUTH_REPORT: "true"
DAST failed to find a login form when loading the login page, often because the authentication URL could not be loaded. The log reports a fatal error such as:
2022-12-07T12:44:02.838 INF AUTH loading login page LoginURL=[authentication URL]
2022-12-07T12:44:11.119 FTL MAIN authentication failed: login form not found
Suggested actions:
DAST_AUTH_URL is correct.DAST_AUTH_URL.DAST_AUTH_BEFORE_LOGIN_ACTIONS is valid if used.If DAST captures the wrong authentication tokens during the authentication process then the scan can't crawl authenticated pages. Names of cookies and storage authentication tokens are written to the log. For example:
2022-11-24T14:42:31.492 INF AUTH authentication token cookies names=["sessionID"]
2022-11-24T14:42:31.492 INF AUTH authentication token storage events keys=["token"]
Suggested actions:
Login submit to verify that the login worked as expected.DAST_AUTH_COOKIE_NAMES.DAST failed to find the username, password, first submit button, or submit button elements. The log reports a fatal error such as:
2022-12-07T13:14:11.545 FTL MAIN authentication failed: unable to find elements with selector: css:#username
Suggested actions:
Login page to verify that the page loaded correctly.DAST_AUTH_USERNAME_FIELD, DAST_AUTH_PASSWORD_FIELD, DAST_AUTH_FIRST_SUBMIT_FIELD, and DAST_AUTH_SUBMIT_FIELD are correct.DAST failed to authenticate due to a failed login verification check. The log reports a fatal error such as:
2022-12-07T06:39:49.483 INF AUTH verifying if login attempt was successful true_when="HTTP status code < 400 and has authentication token and no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.484 INF AUTH requirement is satisfied, HTTP login request returned status code 303 url=http://auth-manual:8090/login want="HTTP status code < 400"
2022-12-07T06:39:49.513 INF AUTH requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
2022-12-07T06:39:49.589 INF AUTH login attempt failed error="authentication failed: failed to authenticate user"
2022-12-07T06:39:53.626 FTL MAIN authentication failed: failed to authenticate user
Suggested actions:
requirement is unsatisfied. Respond to the appropriate error.Applications typically display a dashboard when the user logs in and the login form with an error message when the username or password is incorrect.
This error occurs when DAST detects the login form on the page displayed after authenticating the user, indicating that the login attempt failed.
2022-12-07T06:39:49.513 INF AUTH requirement is unsatisfied, login form was found want="no login form found (no element found when searching using selector css:[name=username] or css:[name=password] or css:button[type=\"submit\"])"
Suggested actions:
Request for the Login submit is correct.Login submit request and response are empty. This occurs when there is no request that would result
in a full page reload, such as a request made when submitting a HTML form. This occurs when using websockets or AJAX to submit the login form.DAST_AUTH_SUCCESS_IF_AT_URL
or DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND to use an alternate method of verifying the login attempt.DAST cannot find an element matching the selector provided in DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND on the page displayed following user login.
2022-12-07T06:39:33.239 INF AUTH requirement is unsatisfied, searching DOM using selector returned no results want="has element css:[name=welcome]"
Suggested actions:
Login submit to verify that the expected page is displayed.DAST_AUTH_SUCCESS_IF_ELEMENT_FOUND selector is correct.DAST detected that the page displayed following user login has a URL different to what was expected according to DAST_AUTH_SUCCESS_IF_AT_URL.
2022-12-07T11:28:00.241 INF AUTH requirement is unsatisfied, browser is not at URL browser_url="https://example.com/home" want="is at url https://example.com/user/dashboard"
Suggested actions:
Login submit to verify that the expected page is displayed.DAST_AUTH_SUCCESS_IF_AT_URL is correct.The HTTP response when loading the login form or submitting the form had a status code of 400 (client error) or 500 (server error).
2022-12-07T06:39:53.626 INF AUTH requirement is unsatisfied, HTTP login request returned status code 502 url="https://example.com/user/login" want="HTTP status code < 400"
Request for the Login submit is correct.DAST could not detect an authentication token created during the authentication process.
2022-12-07T11:25:29.010 INF AUTH authentication token cookies names=[]
2022-12-07T11:25:29.010 INF AUTH authentication token storage events keys=[]
2022-12-07T11:25:29.010 INF AUTH requirement is unsatisfied, no basic authentication, cookie or storage event authentication token detected want="has authentication token"
Suggestion actions:
Login submit to verify that the login worked as expected.DAST_AUTH_COOKIE_NAMES.