Authenticated scanning
Much of an application’s risk lives behind a login. To let Vortex test there, you give it test users — saved sets of credentials that Vortex uses to sign in during a scan. Test users are saved per site and reused across scans, so you configure them once rather than re-entering credentials every time.
Where to manage test users
Section titled “Where to manage test users”Test users live with the scan you’re setting up:
- Go to Vortex → Run scan and pick the target site (test users are per-site, so the site determines which test users you see).
- On the Authentication card, choose Manage to open the test-user drawer.
- From the drawer you can list, add, test, and remove the site’s test users.
Managing test users requires the manage test users permission; see Allow-rules. It isn’t tied to a subscription tier.
Creating a test user
Section titled “Creating a test user”In the drawer, choose to add a test user and provide:
- A name to identify it (unique within the site), and an optional role.
- An authentication type — the options depend on whether the site is a web application or an API.
- The credentials for that type (see below).
Authentication types
Section titled “Authentication types”The available types depend on the site type.
Web application sites
| Type | What you provide |
|---|---|
| Form | The login URL, the username and password field names and values, and any extra form fields. |
| JWT | A JWT token (and, optionally, a custom header name and token prefix). |
| Puppeteer | A Puppeteer browser-automation script (a .js file) and a timeout. Best for complex logins. |
| AI | The login URL, plain-language sign-in instructions, a username and password, and step/time limits. Vortex performs the login interactively. |
API sites
| Type | What you provide |
|---|---|
| Bearer | A bearer token. |
| Basic | A username and password (HTTP Basic auth). |
| Headers | One or more custom header name/value pairs. |
Both site types also offer None (no authentication).
Testing credentials
Section titled “Testing credentials”After you create a test user, use Test credentials to confirm they work. The test runs in the background and the test user shows a status:
| Status | Meaning |
|---|---|
| Untested | You haven’t tested the credentials yet. |
| Testing | A test is currently running. |
| Valid | The credentials authenticated successfully. |
| Invalid | The test ran but sign-in failed (for example, a wrong password or an unreachable login). |
| Error | Something went wrong while testing. |
Testing is optional but strongly recommended.
Using a test user in a scan
Section titled “Using a test user in a scan”On the Authentication card of the Run scan page, pick a saved test user from the dropdown. Vortex signs in with it and exercises the authenticated surfaces of your application. Selecting a saved test user overrides any manual authentication fields on that card.
This works for every Vortex scan type — see Analog, AI pen-test, and API scans.
Good practice and limits
Section titled “Good practice and limits”- Use dedicated test accounts. Prefer purpose-made test credentials over real production accounts, and rotate them periodically.
- Credentials are stored securely. Test-user credentials are encrypted at rest.
- Editing isn’t available yet. To change a test user’s credentials, delete it and create a new one.
- Test users are per-site. Two sites need their own test users, even if the username and password are the same.