Skip to main content
Authenticated scanning tests your application while logged in as a user. It reaches protected areas that anonymous scans miss.
Authenticated scanning is available on Deep and Custom scan types. It’s not available on Light scans.

​
Before you begin

Before configuring authenticated scanning, check that you have:
  • Test account credentials: Dedicated accounts for scanning (not production user accounts)
  • Extended session timeout: Session configured to last longer than your scan duration
  • CAPTCHA/2FA disabled: Neither automatic nor recorded authentication supports CAPTCHA or 2FA. Use Cookie or Header authentication with a pre-authenticated session, or disable them on test accounts.
  • Logout URLs identified: To add to scan exclusions and prevent accidental logout

​
Supported tools

ToolAuthentication methods
Website ScannerAutomatic login form, Recorded, Cookies, Headers
API ScannerHeaders (JWT, Authorization)
WordPress ScannerBasic authentication (username/password)
URL FuzzerHeaders (JWT, Authorization, Cookies, User-Agent)
SQLi ExploiterCookie header
SniperSSH, WinRM, SMB, MySQL
Kubernetes ScannerService account token (JWT)

​
Website Scanner

The Website Scanner supports four authentication methods to handle different application types.

​
Automatic login form

The scanner automatically fills in and submits a login form. This method uses a two-stage approach:
  1. Traditional detection: Pattern-based selectors identify standard login form elements
  2. AI-powered fallback: If traditional detection fails, AI-enhanced authentication takes over to handle complex pages with iframes, dynamic loading, or non-standard layouts
This makes it suitable for simple and complex login forms alike. Requirements:
  • No CAPTCHA, 2FA, or SSO
How to configure:
  1. Enter the Login URL where your login form is located
  2. Provide the Username and Password
  3. Use Check authentication to verify the credentials work
You don’t need to configure anything for AI detection. It activates automatically when needed. See AI-enhanced authentication for details on how it works.

​
Recorded authentication

Record your login steps using Chrome’s Recorder panel and upload the JSON file. Best for complex login flows with multiple steps, redirects, or JavaScript-heavy forms.
1

Open Chrome DevTools

Right-click on your login page and select Inspect, then navigate to the Recorder tab (you may need to enable it from the three-dot menu > More tools > Recorder).
2

Create a new recording

Click Create a new recording and give it a name.
3

Perform the login

With recording active, perform a complete login exactly as you normally would. Enter credentials, click buttons, handle any intermediate screens.
4

Stop and configure

Click End recording. Set the Timeout to at least 15000ms (15 seconds) to allow for network delays.
5

Export as JSON

Click the export icon and select JSON format.
6

Upload to scanner

In the Website Scanner, select Recorded authentication and upload the JSON file.
Use the Recorded method for multi-step login flows: multiple pages, pop-ups, or JavaScript-heavy forms.
Provide session cookies from an already-authenticated browser session. This works with nearly any web application that uses cookies for authentication.
Keep your authenticated session active in the browser for the entire scan duration. If you log out or the session expires, the scan will fail.
How to get session cookies:
1

Log in to your application

Open your browser and log in to the target web application normally.
2

Open Developer Tools

Press F12 or right-click and select Inspect.
3

Navigate to cookies

Go to the Application tab (Chrome/Edge) or Storage tab (Firefox), then expand Cookies and select your target domain.
4

Copy cookie values

Identify session-related cookies (often named PHPSESSID, session_id, auth_token, etc.) and copy the name-value pairs.
Format: 
cookie_name1=cookie_value1; cookie_name2=cookie_value2
Example: 
PHPSESSID=abc123def456; auth_token=xyz789; user_session=active
The cookie header should only contain the cookie name and value pairs, separated by semicolons. Do not include the Cookie: prefix.
Troubleshooting cookie authentication:
IssueCauseSolution
Authentication check failsInvalid or expired cookiesRe-login and get fresh cookies
Scan fails after startingSession expired during scanIncrease cookie lifetime in your application, or keep the browser session active
Blank authentication check windowWrong cookies providedVerify you copied the correct session cookies
Cookie size errorCookies exceed 5000 charactersThis is a platform limitation. Use Header authentication instead

​
Header authentication

Set custom HTTP headers sent with each request. Useful for JWT tokens, Authorization headers, API keys, or any custom authentication headers. Format: 
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-Custom-Auth: your-token-here
Cookie: session_id=abc123
Each header should be on a separate line. You can combine multiple headers including cookies.
Common header examples:
Use CaseHeader Format
JWT Bearer tokenAuthorization: Bearer <token>
Basic authenticationAuthorization: Basic <base64-encoded-credentials>
API keyX-API-Key: <key>
Custom tokenX-Auth-Token: <token>

​
API Scanner

The API Scanner supports header-based authentication for APIs using JWT tokens, Bearer tokens, or custom authorization schemes. How to configure:
  1. In the scan configuration, locate the Headers section
  2. Enter your authentication headers (one per line)
Format: 
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-API-Key: your-api-key-here
If your API uses multiple authentication mechanisms (e.g., both a Bearer token and an API key), include all required headers.

​
WordPress Scanner

The WordPress Scanner supports HTTP Basic Authentication with username and password. This is available in Custom scan mode only. How to configure:
  1. Select Custom scan type
  2. Enable Basic Authentication
  3. Enter your WordPress username and password
Basic Authentication is different from WordPress login credentials. It’s typically configured at the server level (Apache/Nginx) to restrict access to the entire site or wp-admin area.

​
URL Fuzzer

The URL Fuzzer supports custom headers in Custom scan mode, allowing you to fuzz authenticated endpoints. How to configure:
  1. Select Custom scan type
  2. Navigate to Request options > Headers
  3. Enter your authentication headers
Use for:
  • JWT tokens
  • Authorization headers
  • Cookies
  • Custom User-Agent strings
  • Any other custom headers required by your application
Example: 
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cookie: session_id=abc123
User-Agent: Custom-Scanner/1.0

​
SQLi Exploiter

The SQLi Exploiter lets you provide a cookie header in the Advanced options to test authenticated pages for SQL injection vulnerabilities. How to configure:
  1. In the scan configuration, expand Advanced options
  2. Enter your session cookie in the Cookie field
Format: 
PHPSESSID=abc123; auth_token=xyz789
The SQLi Exploiter uses cookies to maintain session state while testing vulnerable parameters on authenticated pages.

​
Sniper

Sniper supports authenticated scans via four protocols. Use them to extract system artifacts through an authenticated session.
Authenticated Sniper scans don’t search for vulnerabilities or run exploits. Instead, they extract artifacts (system information, configurations, user data) through the authenticated session. This is useful for post-authentication reconnaissance.
ProtocolAuthentication optionsUse case
SSHUsername/password or SSH private keyLinux/Unix systems
WinRMUsername/password with auth type (NTLM or Basic)Windows systems
SMBUsername/password with optional domainWindows file shares
MySQLUsername/password with database nameDatabase servers

​
SSH authentication

Username/Password:
  1. Select SSH protocol
  2. Choose Username and Password authentication
  3. Enter SSH credentials
SSH Private Key:
  1. Select SSH protocol
  2. Choose SSH private key authentication
  3. Paste your private key content
  4. Enter the key passphrase (if applicable)

​
WinRM authentication

  1. Select WinRM protocol
  2. Enter username and password
  3. Choose authentication type:
    • NTLM (recommended for domain environments)
    • Basic (for standalone systems)

​
SMB authentication

  1. Select SMB protocol
  2. Enter username and password
  3. Optionally specify the domain for domain-joined systems

​
MySQL authentication

  1. Select MySQL protocol
  2. Enter username and password
  3. Specify the database name to connect to

​
Kubernetes Scanner

The Kubernetes Scanner supports authenticated scanning using a Kubernetes service account token. This simulates an authenticated adversary with valid cluster credentials.
Authenticated scanning is only available in Deep and Custom scan modes. It’s not available in Light scans.
What authenticated scanning reveals:
  • Internal misconfigurations not visible externally
  • What an attacker with valid credentials could access
  • Privilege escalation paths within the cluster
  • RBAC issues and excessive permissions
How to configure:
  1. Select Deep or Custom scan type
  2. Enable Authentication
  3. Paste your Service account token
Token format: The service account token must be a valid JWT (JSON Web Token) in the format: 
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Ii...
How to get a service account token: 
kubectl create token <service-account-name> -n <namespace>
Or for older clusters: 
kubectl get secret <service-account-secret> -n <namespace> -o jsonpath='{.data.token}' | base64 -d
Create a dedicated service account for security testing with appropriate permissions. Avoid using highly privileged accounts like cluster-admin unless specifically testing privilege escalation.

​
Best practices

Never use production user accounts. Create dedicated test accounts with appropriate permissions for scanning. This protects real user data and provides a controlled testing environment.
Web scans can take several hours to complete. Ensure your session cookies or tokens don’t expire during the scan. If possible, increase the session lifetime in your target application during testing.
Multi-factor authentication prevents automated scanning. Disable it for test accounts, or use Cookie or Header authentication with a pre-authenticated session.
Configure scan exclusions to prevent the scanner from accidentally logging itself out during testing. Common patterns to exclude: /logout, /signout, /session/destroy.
For comprehensive coverage, run authenticated scans with different user roles (regular user, admin, limited access) to identify privilege escalation issues and role-based access control flaws.
Always use the Check authentication button before starting a full scan. This validates that your credentials or cookies are working correctly and saves time troubleshooting failed scans.

​
Troubleshooting

​
Authentication check fails

  • Verify credentials are correct and the account is not locked
  • Ensure the target is reachable from the scanner
  • Check that the login URL is correct (may differ from target URL)
  • Confirm the login form is compatible with automatic authentication
  • For cookie auth, ensure cookies haven’t expired

​
Scan starts but loses authentication

  • Session cookies may have expired. Increase session lifetime in your application
  • The scanner may have triggered a logout. Add logout URLs to exclusions
  • Tokens may have a short lifetime. Use longer-lived tokens or refresh mechanism
  • For cookie auth, ensure you keep your browser session logged in throughout the scan

​
CAPTCHA or 2FA blocking authentication

  • Remove CAPTCHA from the test environment during scanning
  • Disable 2FA for test accounts
  • Use Cookie or Header authentication with a pre-authenticated session

​
Authentication works but scan finds nothing

  • The authenticated session may have insufficient permissions
  • Check that the test account has access to the areas you want to scan
  • Verify the scan scope includes authenticated-only paths