Docs menu

Best Practices

Security

At xcelera we take security seriously. This page covers how your account and data are protected, and recommendations for using xcelera securely.

Account security

Creating an account

You can create an account with an email and password, or with your Google or GitHub account.

Protecting your account

Once you have an account, Settings → Security lets you strengthen and manage it:

  • Two-factor authentication (recommended): add a second factor with any authenticator app. Once enabled, sign-in asks for a six-digit code alongside your password.
  • Passkeys: register a passkey (Face ID, Windows Hello, a hardware key) and skip the password.
  • Password: set a password if you signed up with Google or GitHub, or rotate your existing one.
  • Connections: manage which Google or GitHub accounts are linked to your xcelera account.
  • Sessions: see how many devices are signed in and sign out everywhere else in one click.

Your data

Full audit reports are kept for 30 days on the Free plan and 2 years on paid plans; Usage & billing has the details.

From Settings → Data & privacy you can download your account data (your profile, sessions, and roles) as JSON at any time.

The same page lets you delete your personal account. Deletion is self-serve, immediate, and permanent. On the Free and Pro plans it removes your account and everything associated with it: pages, audit history, and API tokens. On a Team plan it removes your user account data only, since pages and audit history belong to the team. To delete a team organization, contact support.

Ephemeral audit infrastructure

Every audit runs on a fresh machine created for that one audit and destroyed when it finishes. Audits never share an environment, so nothing can leak between audits or between organizations. Nothing from your pages stays on our infrastructure after the audit completes.

Secure page credentials

Audits of authenticated pages need cookies or headers to get past your login. xcelera never holds these at rest.

Credentials are accepted only at the moment you trigger an audit through the API or CLI, and they can't be saved on a page. The intended flow is for your CI job to log in against your own API and pass a short-lived session token that expires soon after the audit.

When credentials arrive, the app encrypts them with a key held in a cloud key management service. The app's permission on that key is encrypt-only: it can seal credentials but never read them back. Only the ephemeral machine running your audit can decrypt them. It does so at boot, uses them for that single audit, and self-destructs when the audit ends.

Use short-lived tokens or session cookies where possible, and scope them to a test account. This limits the exposure if credentials leak.

API tokens

API tokens are shown once at creation and stored as hashes. A lost token can't be recovered; deactivate it in Settings → API Tokens and create a replacement. Tokens can be created as read-only, and this is recommended for use with the MCP server.

Webhooks

Every webhook request is signed so you can confirm it came from xcelera. Verify the X-Xcelera-Signature header and reject requests with a stale X-Xcelera-Timestamp to prevent replays. Webhooks has the verification steps and example code.

Help