WrightTest WrightTest

Security

Security

WrightTest is designed as a self-hosted browser check platform for trusted internal teams. Because WrightTest runs browser sessions, stores run artifacts, and can send alerts to external services, you should treat it as an internal testing system and protect it accordingly.

Security model

WrightTest is intended to run in a trusted environment controlled by your team. It is not designed to be exposed as a public anonymous SaaS without additional hardening.

  • Require authentication for all application access.
  • Do not expose admin or project pages to anonymous users.
  • Run WrightTest behind HTTPS in production.
  • Restrict access to trusted team members.
  • Use strong secrets in .env.
  • Keep the host, Docker images, and dependencies updated.

Sensitive data in screenshots and traces

WrightTest can store screenshots, Playwright traces, raw error messages, page URLs, DOM snapshots, network information, and console output. These artifacts may contain sensitive information from the tested application.

  • User emails.
  • Internal URLs.
  • Form values.
  • Session-dependent UI state.
  • API responses visible in the browser.
  • Error messages and accidentally rendered tokens.

Secrets and environment variables

WrightTest uses two kinds of configuration values: application secrets in .env and project environment variables inside the UI.

Application secrets

Do not commit .env files. Use strong random values, rotate secrets if they are exposed, and restrict access to server files and logs.

Project environment variables

Store only values needed for browser checks. Avoid exposing secrets in screenshots or visible page content, and mask sensitive variables in the UI when possible.

Alert tokens and webhooks

Telegram bot tokens, Telegram chat IDs, and Slack incoming webhook URLs should be treated as secrets.

  • Do not share bot tokens or webhook URLs publicly.
  • Rotate a Telegram bot token if it is exposed.
  • Revoke and recreate Slack webhook URLs if they are exposed.
  • Limit who can create or edit alert channels.
  • Use test notifications to verify configuration before relying on alerts.

Authentication and access control

Protect access to WrightTest with authentication. Use strong passwords, change default or initial credentials after setup, do not share user accounts, and restrict network access where possible.

If WrightTest is deployed for a team, consider additional network controls such as VPN, private network rules, or reverse-proxy access restrictions.

Network exposure

Do not expose internal services directly. Expose only the application entry point, keep database, Redis, noVNC, and backend internals restricted to the Docker or private network when possible, and use a reverse proxy for HTTPS.

Services such as database and Redis should not be reachable from the public internet.

noVNC recorder

The recorder lets users interact with a browser session through the web UI, so only authenticated users should access recorder sessions. Recorder sessions should not be public.

  • Do not record workflows that expose secrets unless necessary.
  • Close unused recording sessions.
  • Monitor logs for recorder failures or unexpected access.

Responsible use

WrightTest is designed for testing applications you own or are authorized to test.

  • Do not use WrightTest to test third-party systems without permission.
  • Do not automate abusive traffic.
  • Do not bypass access controls.
  • Do not collect data from systems you are not allowed to access.

Reporting security issues

Please do not open a public GitHub issue for vulnerabilities that expose credentials, bypass authentication, leak artifacts, or allow unauthorized access.

For now, report security-sensitive issues through GitHub Security Advisories if available. For non-sensitive bugs, use GitHub Issues.

If you do not have a dedicated security email yet, keep the report private and avoid posting sensitive details publicly.

Known limitations

  • WrightTest is currently intended for trusted internal or self-hosted usage.
  • It is not hardened as a public multi-tenant SaaS.
  • Browser execution currently uses Chromium.
  • Screenshots and traces may contain sensitive data.
  • Access control should be reviewed before exposing WrightTest outside a trusted network.
  • Public anonymous usage is not recommended.