Authenticated audits

Reuse a protected test session

A test session is a named authentication credential saved for one verified domain. Full and custom audits can reuse it, so you do not need to recover or paste the secret for every run. Light audits always remain public.

VICE encrypts saved secrets. Only verification and audit workers use them. Your password is never needed.

Saved sessions stay with the verified domain and can be searched, edited, rotated, or revoked.

• Create up to five sessions per verified domain.
• Choose an expiration from one hour to thirty days.
• Credentials stay on the verified website or the exact Supabase project configured for its session.

Choose the authentication method

Use the same method that a successful signed-in request already uses. Open your application with a dedicated test account, then inspect a protected request in browser developer tools before creating the session.

Inspect a successful same-origin request and copy only the authentication value required by the selected method.

• Supabase Auth
• Bearer token: the request contains an Authorization header whose value starts with Bearer.
• Cookie header: the browser authenticates the request with one or more first-party cookies.
• Custom header: the application uses another header such as x-api-key or x-auth-token.

Obtain a Bearer token

A Bearer token is a secret access token: any system that possesses a valid token can present it to the server. It is often a JWT, but not every Bearer token uses the JWT format. Treat the entire value as a password-equivalent secret.

Sign in with the dedicated test account, open Developer Tools > Network, reload a protected page, and select a same-origin request that succeeds only while signed in. Under Headers > Request Headers, look for Authorization: Bearer followed by the token.

• VICE accepts the user token with or without the Bearer prefix.
• If no Authorization header appears, the application probably authenticates with cookies or a custom header instead.

1Observed request
2Authorization: Bearer eyJhbGciOi...
3 
4Paste into VICE
5eyJhbGciOi...

Supabase Auth

If your application uses Supabase login, choose Supabase Auth. A Bearer token alone may not restore the browser session.

Sign in with a test account. In browser developer tools, open Application > Local Storage or Session Storage. Under your website, copy the JSON value of sb-<project-ref>-auth-token into the optional session import field.

Use a publishable key or legacy anon key. Secret and service-role keys are refused.

• The access token identifies the account; the refresh token renews its session. Copy both from the same login, never just the field names.
• VICE fills both tokens and detects the project URL. Add the publishable key from your Supabase settings. Use Enter tokens manually only if you cannot import the session.
• Use a private page on your website, not the Supabase API. Signing out or revoking access can invalidate the session before its VICE expiration.

Obtain a Cookie header

A session cookie is a name-value pair that the browser sends to the application after login. A request can use several cookies, but the audit should receive only the first-party session cookies needed for authentication, not analytics or advertising cookies.

In Developer Tools, inspect a successful protected request under Network > Headers > Request Headers and copy the Cookie value. You can also inspect Application > Storage > Cookies to identify the relevant first-party session cookie, including an HttpOnly cookie that application JavaScript cannot read.

• Paste only name=value pairs separated by semicolons.
• Do not include the Cookie: header name.
• Keep the domain and path scope in mind; a cookie that belongs to another host cannot authenticate the verified origin.

1Observed request
2Cookie: session=abc123; refresh=def456
3 
4Paste into VICE
5session=abc123; refresh=def456

Obtain a custom authentication header

Some applications authenticate API requests with a product-specific header instead of Authorization or Cookie. Inspect a successful protected request in Network > Headers > Request Headers and identify the stable header that carries the credential.

• Enter the header name separately, for example x-api-key or x-auth-token.
• Paste only the raw header value into the secret field, without the header name or colon.
• Do not use routing or transport headers such as Host, Origin, Referer, Connection, Content-Length, Transfer-Encoding, or Proxy-Authorization.

1Observed request
2x-auth-token: test_abc123
3 
4Header name in VICE
5x-auth-token
6 
7Secret in VICE
8test_abc123

Page accessible after sign-in

You can leave this field empty. VICE looks for a private page automatically by following links and redirects on your website, then checks it with and without your test session. A page found successfully is remembered, but access is checked again before every audit.

If VICE cannot find a page that proves private access, choose Choose a page manually in the check result, or open Advanced settings and fill in Page accessible after sign-in. Existing saved page addresses are kept; clear the field to switch to automatic detection.

This is an existing page in your application that requires signing in, such as the account area or dashboard. VICE opens this same page with and without your test session to check that it really gives access to the private area.

Sign in to your application with the test account, open a private page that this account can access, and copy its final address from the browser address bar. Paste that address into Page accessible after sign-in. For example, https://app.example.com/dashboard or just /dashboard. Replace this example with your actual page address and keep the same uppercase and lowercase letters.

Open the same address in a private browsing window without signing in. It should ask you to sign in or deny access to the private area. If it shows the same private content, choose another page. Keep your original test account window signed in: signing out can invalidate the session you copied.

Leave the page empty for automatic detection, or enter a private page under Advanced settings.

• Use the exact website saved as the domain in VICE. For a test environment, use its address, not the production website. With Supabase Auth, use your application page, not the Supabase dashboard or API URL.
• Do not use the sign-in page, a public home page, a login callback, or a one-time sign-in link. Do not include a token or other secret in the address.
• Choose a page that is safe to open: viewing it must not create, delete, purchase, or send anything.
• You do not need to create a special page or change your code. This page is the access check and an entry point for discovery, not the only page the audit can inspect.
• Confirmation text under Advanced settings is optional. If needed, enter a stable label already visible only after signing in, such as Account settings. Do not add new text to your application or use a name, email address, or changing value. To remove previously saved confirmation text, select its removal checkbox; leaving the field blank keeps it.
• A valid Supabase token does not guarantee access to your application: the test account may still lack a role or access to a workspace. An unsuccessful page check does not necessarily mean the token has expired.

Save and check access

Save and check access stores the session, then compares the page with and without it. This free check may wait for a worker. An unsuccessful check leaves your session saved and editable.

Verified access confirms a difference on this page, not complete coverage of your application. The result explains a failed check: return to login, missing confirmation text, public page, or unavailable connection.

This connection check does not use an audit credit.

Select the session for an audit

From the domain overview or Audits page, choose Start audit. Select Full or Custom, switch Application access to Test session, and choose an active named session from the dropdown.

Select a saved session only for full or custom coverage that needs protected routes.

• Light audits do not use a test session.
• The audit stores the selected session reference instead of copying the secret into audit history.
• Each audit checks access again. If access is not verified, security checks stop and the reserved quota or credit is restored. Choose Public surface to audit without a session.

Rotate or revoke the session

Use the pencil icon under Domain settings > Test sessions to rename the session, adjust its protected path or marker, rotate the credential, or revoke it.

• Leave New session secret empty to keep the encrypted credential and its current expiration.
• Provide a new secret to rotate the credential and apply a new expiration.
• Remove session opens a confirmation dialog and revokes the session immediately.