Why Authenticated Pentesting Matters

Many critical vulnerabilities — broken access control, privilege escalation, IDOR — only exist behind authenticated endpoints. Without credentials, APVISO can only test the unauthenticated attack surface. Authenticated pentesting gives the agents a valid session so they can test the full application.

Where Credentials Live

Target application credentials live only on the self-hosted runner. Configure a local JSON file on the runner host and set APVISO_TARGET_AUTH_CONFIG_FILE=/path/to/target-auth.json. The runner mounts that file read-only into the pentest container. APVISO Cloud receives job state and findings, but not tokens, cookies, passwords, or login secrets.

Supported Authentication Methods

Bearer Token

Provide a static bearer token. The pentest sends it in the Authorization: Bearer <token> header on authenticated requests.

Basic Auth

Supply a username and password. The pentest encodes them and sends the Authorization: Basic <encoded> header.

Cookie

Provide a session cookie name and value. This is useful when your application uses cookie-based sessions.

API Key

Specify the header name and key value, such as X-API-Key.

Custom Headers

Add one or more arbitrary request headers for non-standard authentication schemes.

Login-Based Auth

For applications with a login form, provide the login URL, username, and password in the runner-local file.

Example Runner File

{
  "targets": {
    "app.example.com": {
      "type": "bearer",
      "token": "local-only-token"
    }
  }
}

Best Practices

Use a dedicated test account with realistic but non-admin privileges for the initial pentest. Run a separate pentest with admin credentials if needed.
Store the runner-local file with restrictive permissions and rotate or revoke credentials after pentesting.
Prefer token-based auth over login-based auth when possible.
Test that the credentials work from the runner network before starting the pentest.