Web App Authentication & the Credential Vault¶

Audience: Client owners and managers (the people who create assessments and manage saved credentials) · Where: the Credentials section of the create-assessment flow for a web application, and Administration → Credentials (/administration?tab=credentials).

Overview¶

Most real vulnerabilities in a web application sit behind its login page. To test as a signed-in user, give Canima one or more login identities: accounts the scanner signs in as. With accounts from different roles or tenants, Canima can also check whether one user can reach another user's data, a common and serious class of flaw.

Identities can be entered once for a single assessment, or saved to the Credential Vault and reused across assessments. The vault also holds the credentials used for authenticated internal and external network testing.

Secrets are write-only

Passwords, tokens, client secrets and TOTP secrets are stored encrypted and never shown again after you save them. You can replace a secret, but nobody can read it back in the portal.

When you create a web application assessment, open the Credentials section and find Login identities (optional). You can add up to 10 identities per assessment. For each one, either:

pick one from Add a saved identity (Pick from the vault…), or
click Add a new identity and enter its details.

Fields for each identity¶

Field	What it's for
Label	A short name for the role, such as `tenant_a_admin`. Lowercase letters, numbers, `_` and `-` only, and each label must be unique within the assessment.
Tenant (optional)	Which tenant or customer account this user belongs to, such as Tenant A. Lets Canima test isolation between tenants.
Privilege	Admin, Privileged, Standard user, Read-only or Guest (or Not set). Lets Canima test whether a lower-privilege user can do what only a higher one should.
Primary login	"Primary login (crawling and general testing run as this identity)." Only one identity can be primary.
Type	Web login (username/password), Web token / API key or OAuth client credentials. The remaining fields depend on the type.
Allowed origins (optional)	The exact origins (for example `https://app.example.com`) this identity may be sent to. See below.

Web login (username/password)Web token / API keyOAuth client credentials

Username and Password.
TOTP secret (optional, base32): for accounts protected by an authenticator app. Canima generates the current code at sign-in. When you enter one, TOTP digits (6 or 8) and TOTP period (30 or 60 seconds) appear.
Login URL (optional): the login page, as a path (/login) or a full URL.
Username field name (optional): the name of the username input, if it is unusual.
Login style: Detect automatically (default), HTML form, JSON API or HTTP Basic.

Token: the token or API key.
Send the token as: Authorization: Bearer (default), A named header (then enter the Header name, for example X-Api-Key) or A cookie (then enter the Cookie name).

Token URL: the OAuth token endpoint, for example https://auth.example.com/oauth/token.
Client ID and Client secret.
Client authentication: Secret in request body or HTTP Basic.
Scope (optional) and Audience (optional).

To keep a new identity for future assessments, tick Save to vault for reuse on other assessments and give it a nickname (required to save).

Allowed origins¶

Canima only sends an identity's credentials to the origins you allow. If you leave Allowed origins empty:

a vault identity is pinned to the assessment's target, and
a one-off identity is limited to the target and the hosts you listed in scope.

List every origin the login flow really uses. If sign-in goes through a separate domain, also see the next section.

If the application signs users in through an external identity provider (for example Okta, Auth0, Cognito or a custom OIDC provider), turn on Authentication handled by a 3rd-party provider? in the assessment's configuration. Then enter:

Provider name, and
In-scope provider hosts: the provider's login hosts, comma- or newline-separated (for example login.example.com).

These hosts are added to the assessment's secondary in-scope targets so the sign-in flow can complete.

Common validation messages¶

"At most 10 identities per assessment"
"… isn't a valid label: use a-z, 0-9, _ or -" and "The label … is used twice"
"Identity … is missing login details"
"Name identity … to save it to the vault": you ticked Save to vault without a nickname.
"Only one identity can be the primary"

After the assessment is created¶

The assessment's Config tab lists its login identities as a read-only record: label, type and username, never secrets. Like the rest of the configuration, identities are fixed once the scan has started. See Assessment Overview.

The Credential Vault¶

Administration → Credentials (in the Scanning group) holds reusable credentials: "Reusable credentials for authenticated vulnerability scanning and pentesting, and login identities for web app testing. Stored encrypted; attach them per engagement in the assessment wizard."

Credential types¶

For	Types
Internal and external network testing	SSH (password), SSH (key), SMB, ESXi, SNMP, LDAP / Domain user
Web application testing	Web login (username/password), Web token / API key, OAuth client credentials

Adding a credential¶

Click New credential.
Enter a Nickname (for example Domain admin (lab)) and choose a Type.
Fill in the secret and login fields for that type. Web identities also need at least one Allowed origin.
Optionally add a Note, for example where the credential is used or when to rotate it.
Save. You'll see "Credential saved".

Managing credentials¶

The vault table shows each credential's Nickname, Type, Username, In use (how many assessments use it) and Updated date. Search with Search credentials… or filter by type. Each row has three actions:

Edit: change the nickname, username, domain, login settings, allowed origins or note. The type can't be changed.
Rotate secret: enter new secret material, for example after a password change. For a login with a stored TOTP secret, you can also remove that secret.
Delete: removes the credential. If it is still used by an active assessment, you'll see "Couldn't delete — it may be in use by an active assessment."

Using vault credentials for network testing¶

For internal, external and Active Directory assessments, the Credentials section of the create-assessment flow offers Add a saved credential from the vault, or a new one with Save to vault for reuse on other engagements. Each credential can be enabled for Use for vulnerability scanning, Use for pentesting, or both. See Running an Assessment.