Auditing Secure Pages Paid

If your page requires authentication — a logged-in dashboard, an admin panel, a gated landing page — you can configure xcelera to include credentials when running Lighthouse.

Why you need this

Without authentication, Lighthouse will see your login page (or a redirect) instead of the actual content you want to audit. Authenticated audits let you measure the real user experience for pages behind a login.

Setting up authentication

When creating or editing a page definition, enable Requires Authentication and provide credentials via cookies or custom headers.

Cookies

Provide one or more cookies to inject into the browser session before Lighthouse runs:

• Name — the cookie name (e.g. session_id)
• Value — the cookie value
• Domain — the domain the cookie belongs to (e.g. example.com)
• Path — optional, defaults to /
• Secure / HttpOnly / SameSite — optional flags to match your cookie configuration

Custom headers

Provide key-value pairs that are sent as HTTP headers with every request during the audit. Useful for API tokens or custom auth headers:

• Authorization: Bearer <token>
• X-Custom-Auth: <value>

How credentials are handled

xcelera takes credential security seriously:

• Credentials are encrypted before being transmitted to the audit infrastructure
• Audits run on ephemeral machines that are destroyed after each test — no credentials persist after the audit completes
• Credentials are never stored in the database beyond the active audit

See Security best practices for more on how xcelera protects your data.

Providing auth via the API

You can also pass authentication credentials when triggering audits via the API. This is useful for CI/CD pipelines where credentials are managed as secrets:

{
	"ref": "admin-dashboard",
	"auth": {
		"cookies": [
			{
				"name": "session",
				"value": "abc123",
				"domain": "example.com"
			}
		],
		"headers": {
			"Authorization": "Bearer my-token"
		}
	}
}

See the API Reference for the full request schema.