Authentication Configuration

Overview

By default, application scans run without authentication, testing your application as an unauthenticated user would encounter it. Authenticated scanning extends this coverage to areas of your application that require a logged-in session — account pages, API endpoints behind auth middleware, admin interfaces, and any route protected by access controls.

Authenticated scanning typically uncovers a significantly larger attack surface than unauthenticated scanning alone, particularly for applications where most functionality sits behind a login wall.

You configure authentication in the Authentication section of the Add Application dialog, or on an existing application’s Settings tab. Pick an authentication method from the tab bar and fill in its fields. Saved secrets (passwords, tokens, client secrets, refresh tokens) are not shown again; leave a secret field blank to keep its current value.

Note

Every method other than No Auth requires the application scan authorization feature on your plan. If your plan does not include it, only unauthenticated scanning is available.

Authentication methods

No Auth

The scanner accesses your application as an unauthenticated user. Scan requests are made without any authentication headers or cookies.

This is the default option and is appropriate when you want to test only the publicly accessible surface of your application, or when your application has no authentication.

Basic Auth

HTTP Basic Authentication sends an Authorization: Basic <base64 username:password> header with every request to your verified domains.

When to use: Simple internal APIs, development environments, or legacy applications using HTTP Basic Auth.

Configuration:

• Username — The account username
• Password — The account password

Caution

Basic Authentication credentials are sent with every request. Ensure the account used for scanning has limited permissions — ideally read-only or scoped to non-destructive operations — to avoid unintended data modifications during scanning.

Bearer Token

Sends an Authorization: Bearer <token> header with every request. This is the standard authentication method for APIs using JWT tokens, OAuth 2.0 access tokens, or any bearer-style credential.

When to use: REST APIs that authenticate via tokens, services using OAuth 2.0 or OpenID Connect, or any application that accepts a static bearer token.

Configuration:

• Bearer token — The full bearer token value (without the Bearer prefix)

Note

The token must remain valid for the entire duration of the scan. Short-lived tokens that expire mid-scan will cause the scanner to receive authentication failures. Use a long-lived token or a service account token where possible.

OAuth2 M2M

Before each scan, Fencer fetches a fresh access token from your token URL using the OAuth 2.0 client-credentials grant, then sends it as a bearer token on every request.

When to use: Machine-to-machine APIs protected by an OAuth 2.0 authorization server.

Configuration:

• Token URL — The authorization server’s token endpoint
• Client ID — The client identifier
• Client secret — The client secret

OAuth2

Before each scan, Fencer exchanges a stored refresh token for a fresh access token and sends it as a bearer token on every request. The refresh token is rotated automatically after each use.

When to use: APIs where you can obtain a refresh token for a scanning account through the OAuth 2.0 authorization code flow.

Configuration:

• Token URL — The authorization server’s token endpoint
• Client ID — The client identifier
• Refresh token — A refresh token obtained via the authorization_code OAuth2 flow

Caution

OAuth2 M2M and OAuth2 are currently applied to MCP scans only. For applications that use another scan method, use Bearer Token, Custom Header, or Login Form instead.

Custom Header

Injects one or more custom HTTP headers into every request to your verified domains. This is the most flexible option, supporting any custom authentication scheme.

When to use: APIs that use a proprietary key header (e.g., X-API-Key), session tokens passed in custom headers, or any application that uses a non-standard authentication mechanism.

Configuration:

• Header name and Header value — One row per header. Click Add header to add another.

Examples of common custom header configurations:

Header Name	Example Value
X-API-Key	sk_live_abc123...
X-Session-Token	eyJhbGciOiJIUzI1NiIs...
X-Auth-User	scanner-service-account

Login Form

The most powerful and complex authentication method. Before the scan, the scanner opens a browser, navigates to your login page, fills in the credentials, and completes the login flow. This produces a real authenticated browser session for the crawl, and the scanner detects automatically whether the login succeeded.

When to use: Web applications with standard login forms, applications that set session cookies via form submission, or any scenario where the other authentication methods do not apply.

Configuration:

• Login page URL — The full URL of the login page
• Username or email — The account username to enter
• Password — The account password to enter
• Additional steps (optional) — An ordered list of steps for multi-step flows. Click Add step, choose a step type, and enter the XPath of the element it acts on:
  • Click Element — clicks the element (e.g., a submit or Continue button)
  • Fill Username / Fill Password — types the credentials above into the element
  • Fill Field — types a custom value (entered in Text to enter) into the element
  • Press Enter — sends Enter to the element
  • Wait for Element — waits for the element to appear before continuing

Note

Login Form is not used for MCP scans.

Login Form XPath selector configuration

XPath selectors identify the elements each additional step acts on. The scanner evaluates each selector against the page DOM to locate the target element.

Common XPath patterns for login forms:

//input[@id='username']
//input[@name='email']
//input[@type='password']
//button[@type='submit']
//button[contains(text(), 'Sign in')]

For multi-step login flows — such as applications that ask for the username and password on separate screens — chain steps, for example Fill Username, Click Element on a Continue button, Wait for Element on the password field, then Fill Password and Click Element on the submit button.

Note

If the login form uses dynamic element IDs that change on each page load, use stable attributes like name, type, or aria-label in your XPath selectors instead of id.

When to use each method

Authentication method	Best for
No Auth	Public-facing pages, applications without auth
Basic Auth	Simple internal APIs, legacy apps with HTTP Basic Auth
Bearer Token	REST APIs with JWT/OAuth, service-to-service APIs
OAuth2 M2M	MCP servers protected by OAuth 2.0 client credentials
OAuth2	MCP servers where you hold an OAuth 2.0 refresh token
Custom Header	API key headers, proprietary auth schemes
Login Form	Web applications with standard login flows

Validation when you save

When you save an application with authentication configured, Fencer tests the configuration and blocks the save with a warning if it fails:

• Basic Auth and Bearer Token — the target must not answer 401 or 403 with the credentials.
• OAuth2 M2M — the token URL must return an access token for the client ID and secret.
• Custom Header — at least one header needs both a name and a value.
• Login Form — the login page URL must be reachable.

After each scan, the application’s Scan Trust tab shows whether the scan was Authenticated, whether authentication failed (Auth failed), or whether it ran Unauthenticated.

Authenticated vs unauthenticated scan differences

Running a scan with authentication enabled extends coverage to:

• Routes and endpoints that return 401 Unauthorized or redirect to login when accessed without credentials
• Application logic that only executes for authenticated sessions (e.g., IDOR vulnerabilities in user-specific data endpoints)
• Authenticated-only injection points such as form fields, API parameters, and file upload handlers
• Session management vulnerabilities that only manifest after login

For most web applications, the authenticated attack surface is significantly larger than the unauthenticated surface.

Examples

Configuring Bearer token authentication for an API

1. Open the application’s Settings tab, or click Add Application to create a new one.
2. Select Bearer Token as the authentication method.
3. Generate a service account API token with the appropriate read/write scope for your API.
4. Paste the token into the Bearer token field.
5. Save. The scanner will include Authorization: Bearer <your-token> on all requests.

Setting up Login Form authentication for a web application

1. Open the application’s Settings tab and select Login Form as the authentication method.
2. Set the Login page URL to https://app.example.com/login.
3. Enter your scanning account’s Username or email and Password.
4. Inspect the login form in your browser’s developer tools to identify element selectors, then add steps:
   • Fill Username with //input[@name='email']
   • Fill Password with //input[@type='password']
   • Click Element with //button[@type='submit']
5. Click Save Changes and run a scan. The scanner completes the login flow before crawling.

Troubleshooting

• Authentication feature not available — Your plan does not include the application scan authorization feature. Contact your administrator to upgrade.
• “Authentication failed during the scan.” — The scan could not sign in. Check the credentials for the method you use (for Login Form: the login URL, username, password, and form selectors), then run the scan again.
• Bearer token expires during scan — Use a non-expiring service account token or a token with a long TTL, or use OAuth2 M2M for MCP scans so a fresh token is fetched before each scan.
• Login Form scan fails to authenticate — Verify that the login URL is correct and reachable from Fencer’s scanning infrastructure. Check that your XPath selectors match the actual DOM elements on the login page using browser developer tools.
• Login Form fails on MFA — Login Form steps are fixed, so they cannot answer dynamic MFA challenges. Use a scanning account that does not require MFA.
• Scan finds no authenticated vulnerabilities — Check the Scan Trust tab, then confirm that the scanning account has sufficient permissions to access the areas of the application you want to test. Check application logs for authentication errors during the scan window.

Related pages

• Application Scanning
• Vulnerability Management