Tutorials / Authentication

Authenticated Scan

🔐 Overview: Why Authenticated Scanning?

Modern enterprise apps often restrict access behind authentication layers. To accurately test access controls, session handling, IDOR, and authorization faults, you must configure an authenticated scan so Prancer operates with valid credentials.

With proper setup, Prancer automatically logs in as a typical user and conducts scans _as though_ a legitimate session is already active.

✅ Step 0: Access the Authentication Panel

1. Go to Inventory Management in the portal.

2. Locate your target item (via filters or search).

3. Click the ⋮ hamburger menu next to it.

4. Select Authentication to open the configuration modal.

( docs.prancer.io)

More advanced users can open PAC manifest files in Inventory Management and modify the YAML file there.

🗃 Vault Security (Azure Key Vault or AWS Secret Manager)

Prancer provides two separate ways to save authentication secrets:

1. Customer Vault : If you have connected to one of the supported Cloud Providers (Azure, AWS, GCP), you can use them and save the secrets in their cloud providers. By doing this, your authentication keys don’t leave your cloud provider and will be used in scanning.

2. Prancer Managed Vault: Prancer leverages Azure Key Vault to save secrets in customer tenants. Each customer will be provided with a dedicated Key Vault, which they can use to save their authentication secrets. Vault is available from the left pane.

Considering you want to use Prancer Vault for complexity. All authentication credentials (usernames, passwords, tokens, client credentials, etc.) must be stored securely in the Prancer‑managed vault. The PAC manifest only references vault keys—not the actual secrets.

This keeps your credentials encrypted and auditable.

( docs.prancer.io)

1\. Form‑Based Authentication (Login form + session cookie)

When to use: Traditional websites with HTML login forms.

Configuration UI Fields:

Vault name (Key Vault or Secret Manager)

Username secret key

Password secret key

Logout URL (optional but helps avoid logging out the session)

( docs.prancer.io)

Sample PAC YAML Snippet:

AuthenticationMethod: formBasedAuthentication Authentication: Vault: Azure: KeyVaultName: MyKeyVault SubscriptionID: YOUR_SUB_ID Region: westus ResourceGp: my‑rg FormBaseAuth: UsernameSecretKey: myUserSecret PasswordSecretKey: myPassSecret LoginUrl: /login LogoutUrl: /logout LoginRequestPostData: username={%username%}&password={%password%} LoginIndicator: \Q<a href="logout">Logout</a>\E

_Everything else in your PAC file remains unchanged._

( docs.prancer.io)

2\. Cookie‑Based Authentication (Manual session cookie in header)

When to use: Apps authenticated via session-cookie, not tokens (e.g. legacy systems or JS-heavy sites).

UI Fields: Same as Form‑based, plus:

LoginBodyTemplate, e.g. identifier={%username%}&password={%password%}

cookieHeaderName (usually Cookie)

cookieSessionName (e.g. sessionID)

extraFields (e.g. lang=en;theme=light)

( docs.prancer.io)

Sample PAC Snippet:

AuthenticationMethod: cookieAuthentication Authentication: Vault: Azure: KeyVaultName: MyKeyVault SubscriptionID: ... Region: westus ResourceGp: my‑rg cookieAuth: UsernameSecretKey: myUser PasswordSecretKey: myPass LoginUrl: /login LogoutUrl: /logout LoginBodyTemplate: identifier={%username%}&password={%password%} LoginIndicator: \Q<a href="/logout">Logout</a>\E cookieHeaderName: Cookie cookieSessionName: sessionID extraFields: lang=en;opt=1

( docs.prancer.io)

3\. JWT Authentication (Token‑based via header)

When to use: APIs or SPAs that return JWTs in login response.

UI Fields:

LoginBodyTemplate (JSON with username/password)

LoginIndicator regex to extract token (e.g. ^.*token.*$)

AuthorizationType: usually Header

AuthorizationKey (e.g. Authorization)

AuthorizationTokenType (e.g. Bearer)

Username and password vault keys

( docs.prancer.io)

Sample PAC Snippet:

AuthenticationMethod: jwtAuthentication Authentication: JWTAuth: UsernameSecretKey: apiUserSecret PasswordSecretKey: apiPassSecret LoginUrl: https://app.company.com/login LogoutUrl: https://app.company.com/logout LoginBodyTemplate: '{"username":"%username%","password":"%password%"}' LoginIndicator: ^.*token.*$ AuthorizationType: Header AuthorizationKey: Authorization AuthorizationTokenType: Bearer Vault: Azure: KeyVaultName: MyKeyVault SubscriptionID: ... Region: eastus ResourceGp: my‑rg

( docs.prancer.io)

4\. OAuth 2.0 Authentication (Client ID/Secret flow only)

When to use: Standard OAuth flows without interactive redirects (e.g., client‑credential or resource owner password grant).

UI Fields:

Same basic fields as other auth types

ClientId, ClientSecret, TenantId keys from vault

LoginBodyTemplate / LoginIndicator

OAuth flow must not require interactive browser redirect (fallback to Custom Auth if it does)

( docs.prancer.io)

Sample PAC Snippet:

AuthenticationMethod: oauthAuthentication Authentication: oAuth: LoginUrl: https://oauth.company.com/token LogoutUrl: https://oauth.company.com/logout LoginBodyTemplate: {"username":"%username%","password":"%password%"} LoginIndicator: XFE8YSBocmVmPSIvdXNlci9sb2dvdXQiPkxvZ291dDwvYT5cRQ== clientId: myClientIdSecret clientSecret: myClientSecretSecret tenantId: myTenantIdSecret Vault: Azure: KeyVaultName: MyKeyVault SubscriptionID: ... Region: eastus ResourceGp: my‑rg

( docs.prancer.io)

5\. Custom Authentication (Headers, Cookies, or Static Tokens)

When to use: Non-standard or multi-step flows that include static tokens, dual headers, pre-set cookies, or chained logic. Defaults to both header and cookie token support.

( docs.prancer.io)

UI Fields:

LogoutUrl

AuthorizationType (header, cookie, or both)

AuthorizationKey (header name)

AuthorizationTokenValue (vault key)

CookieKey, CookieValue, SessionName, SessionValue, ExtraFields

( docs.prancer.io)

Sample PAC Snippet:

AuthenticationMethod: customAuthentication Authentication: CustomAuth: AuthorizationType: header AuthorizationKey: Authorization AuthorizationTokenValue: myStaticTokenSecret CookieKey: "" CookieValue: "" SessionName: "" SessionValue: "" ExtraFields: "" LogoutUrl: https://app.company.com/logout Vault: Azure: KeyVaultName: MyVault SubscriptionID: ... Region: eastus ResourceGp: my‑rg

( docs.prancer.io)

🧪 What Happens After You Submit?

1. Prancer validates that all referenced vault keys exist in your selected vault.

2. It injects the decrypted credential inside the scanner during pentest execution.

3. The scanner performs login, validates success via the login indicator, and attaches session or token to future requests.

4. Penetration tests are carried out in context of the authenticated session.

5. Results appear in Pentest Findings grouped under that target’s PAC file.

✅ Best Practices Checklist

| Task | Recommendation |

| Use Vaults | Never hardcode any username, password, token. For Azure use Key Vault; for AWS use Secret Manager. |

| Test login separately | Use Postman or curl with vault‑sourced creds before configuring Prancer. |

| Define strong regex | LoginIndicator regex helps validate authentication succeeded. |

| Least‑privilege accounts | Use user roles that limit scope—e.g. read-only users. |

| Test with and without auth | Scoped testing covers both public and private attack surfaces. |

| Rotate secrets regularly | Update vault entries and replumb PAC settings. |

| Include Logout URL when possible | Helps Prancer avoid inadvertent logouts during scanning loops. |

Additional Screenshots

Additional screenshots, in order of appearance.