av dast targets auth

Give a DAST scan the credentials it needs to reach pages behind a login, so the scanner tests your authenticated surface instead of stopping at the sign-in wall. There are two ways to supply them, covered below.

The binary ships as alertavuln; av is the common alias - they are interchangeable in every example.

Authorization still applies

Authenticating a scan does not change the rule that you may only scan systems you own or are explicitly authorized to test - see the note on av dast scan. Supply credentials only for targets you control.

Two ways to authenticate

Approach	Use when	Where the secret lives
ALERTAVULN_DAST_AUTH_* environment variables	You run av dast scan yourself (local or CI)	In your shell/CI only - never uploaded
Stored profile (av dast targets auth set)	You want AlertaVuln’s hosted worker to scan on a schedule	Encrypted at rest on the server, per target

Both describe the same five credential kinds - header, bearer, cookie, form, and oauth - with the caveats noted below.

Local scan: environment variables

For a scan you run yourself, set ALERTAVULN_DAST_AUTH_* in the environment before av dast scan. Nothing is stored server-side and no round trip is needed. If ALERTAVULN_DAST_AUTH_KIND is unset the scan runs unauthenticated, exactly as before.

Kind	Required variables	Optional
header	ALERTAVULN_DAST_AUTH_KIND=header, ALERTAVULN_DAST_AUTH_HEADER_NAME, ALERTAVULN_DAST_AUTH_HEADER_VALUE	-
bearer	ALERTAVULN_DAST_AUTH_KIND=bearer, ALERTAVULN_DAST_AUTH_BEARER_TOKEN	-
cookie	ALERTAVULN_DAST_AUTH_KIND=cookie, ALERTAVULN_DAST_AUTH_COOKIE_NAME, ALERTAVULN_DAST_AUTH_COOKIE_VALUE	-
oauth	ALERTAVULN_DAST_AUTH_KIND=oauth, ALERTAVULN_DAST_AUTH_OAUTH_TOKEN_URL, ALERTAVULN_DAST_AUTH_OAUTH_CLIENT_ID, ALERTAVULN_DAST_AUTH_OAUTH_CLIENT_SECRET	ALERTAVULN_DAST_AUTH_OAUTH_SCOPE

What a local authenticated scan covers today

On a local av dast scan, credentials are applied to the template-scanner (it runs its checks as the authenticated user). The web-scanner - the one that crawls the app - does not yet consume these credentials; its authenticated mode ships with hosted DAST. So a local authenticated scan deepens the template checks but still crawls unauthenticated.

kind=form (form login) is not supported for a local scan - it needs the hosted worker. Use header, bearer, cookie, or oauth locally, or store a form profile for a hosted scan (below). Passing ALERTAVULN_DAST_AUTH_KIND=form to a local scan fails fast with that explanation.

Examples

Scan with a static header (for example an API gateway key):

export ALERTAVULN_DAST_AUTH_KIND=header
export ALERTAVULN_DAST_AUTH_HEADER_NAME="X-API-Key"
export ALERTAVULN_DAST_AUTH_HEADER_VALUE="<key>"
av dast scan --target https://staging.example.com

Scan with a bearer token:

export ALERTAVULN_DAST_AUTH_KIND=bearer
export ALERTAVULN_DAST_AUTH_BEARER_TOKEN="<token>"
av dast scan --target https://staging.example.com

Scan with an OAuth client-credentials grant (the CLI fetches a token from the token endpoint before scanning):

export ALERTAVULN_DAST_AUTH_KIND=oauth
export ALERTAVULN_DAST_AUTH_OAUTH_TOKEN_URL="https://id.example.com/oauth/token"
export ALERTAVULN_DAST_AUTH_OAUTH_CLIENT_ID="<client-id>"
export ALERTAVULN_DAST_AUTH_OAUTH_CLIENT_SECRET="<client-secret>"
av dast scan --target https://staging.example.com

Stored profile: av dast targets auth set

Store an encrypted auth profile against a registered target so AlertaVuln’s hosted worker can scan it for you. The secret is encrypted at rest on the server; only the hosted worker decrypts it at scan time.

av dast targets auth set --project <projectId> --target <targetId> --kind <kind> --secret <value> [kind flags]
av dast targets auth clear --project <projectId> --target <targetId>

--target here is the target ID (from av dast targets), not a URL. You must be logged in (av login).

Hosted execution is rolling out

Storing a profile is supported now, and form login is available on this path (it is the hosted worker that performs the login). The hosted scans that consume a stored profile arrive with hosted DAST - until then, a stored profile is held ready but not yet exercised. For a scan you can run today, use the environment-variable path above.

Options

Flag	Kind	Description
--project	all	Project ID (required)
--target	all	Target ID (required)
--kind	all	header, bearer, cookie, form, or oauth (required)
--secret	all	The secret value: header value / bearer token / cookie value / password / client secret (required)
--header-name	header	Header name
--cookie-name	cookie	Cookie name
--login-url	form	Login form URL
--username-field	form	Username field name
--password-field	form	Password field name
--username	form	Username value
--logged-in-indicator	form	Text present only when logged in
--logged-out-indicator	form	Text present only when logged out (optional)
--token-url	oauth	Token endpoint
--client-id	oauth	Client ID
--scope	oauth	Scope (optional)

Examples

Store a bearer token for a target:

av dast targets auth set --project <projectId> --target <targetId> \
  --kind bearer --secret "<token>"

Store a form-login profile (hosted worker signs in before scanning):

av dast targets auth set --project <projectId> --target <targetId> \
  --kind form --secret "<password>" \
  --login-url https://app.example.com/login \
  --username-field email --password-field password \
  --username [email protected] \
  --logged-in-indicator "Sign out"

Remove a stored profile:

av dast targets auth clear --project <projectId> --target <targetId>

Security

Credentials supplied through ALERTAVULN_DAST_AUTH_* stay in your environment - they are never uploaded with a scan’s findings. Stored profiles are encrypted at rest and only decrypted by the hosted worker at scan time. Either way, any credential the scanner sees reflected back in a response is scrubbed from finding evidence before it is uploaded or displayed, the same as every other DAST finding.

See also

• av dast scan - run a scan (reads ALERTAVULN_DAST_AUTH_*)
• av dast targets - list a project’s registered targets and their IDs
• Dynamic scanning (DAST) - what DAST covers, passive vs active, hosted vs self-hosted