Security

Our approach

Security is a design constraint for BrowserBash, not an afterthought. The core principle is local-first: when you run the CLI, it drives a browser and reasons about your pages entirely on your machine. Your objectives, the web pages it visits, screenshots, recordings, variables, and any credentials are processed locally and are not transmitted to us by default.

Data only reaches our servers if you deliberately opt in — by creating an account and linking the CLI with browserbash connect, or uploading a single run with --upload. Nothing is sent silently. Model calls go directly from your machine to the AI provider you choose (a local Ollama model where nothing leaves your computer, a free OpenRouter model, or a key you bring) — we are never in that path.

Secret masking

Credentials are sensitive, so BrowserBash treats them carefully by design. Values you pass as secret variables are masked in logs, console output, and recordings so they do not leak into artifacts you might share or store.

• Never hard-code credentials in your *_test.md files. Reference them through variables instead so they can be supplied at run time.
• Use environment variables or secret variables for passwords, tokens, and API keys. Secret values are masked wherever output is produced.
• Keep secrets out of version control. Because test files are plain Markdown, it is easy to commit them — so keep real credentials in your environment, not in the file.

Data in transit & at rest

All traffic to browserbash.com, the cloud dashboard, and our APIs is served over HTTPS, so data is encrypted in transit. Anything you choose to upload — run metadata and video/screenshot recordings — is stored on managed, access-controlled infrastructure operated by the providers below. Recordings live in Vercel Blob and account and run metadata live in a managed Postgres database, each reachable only through authenticated, scoped access.

Infrastructure & processors

We run the website and optional dashboard on a small set of trusted, industry-standard providers. Each is access-controlled and used only for its stated purpose:

Card details for the optional paid data-retention plan are entered directly with Stripe, a PCI-compliant processor. We receive only a subscription status and customer reference — full card numbers never touch our systems.

Authentication & API keys

Cloud accounts are handled by Clerk, which manages sign-up, login, and session security so we never store raw passwords. The API keys the CLI uses to link to your account (via browserbash connect) are designed to limit blast radius:

• Scoped — a linking key grants only the access the CLI needs to push your runs, nothing more.
• Expiring — keys automatically expire after 30 days, so a leaked key has a short, bounded lifetime.
• Rate-capped — each account has a per-account rate cap to prevent abuse and to limit the impact of a compromised key.

Least privilege & data minimization

We apply least privilege and data minimization throughout. The CLI sends nothing unless you ask it to, and when you do upload a run we collect only what the dashboard needs to show your run history, recordings, and per-run replay. Access to managed infrastructure is restricted, and each processor receives only the data required to perform its specific function. We do not sell your data and we do not train AI models on your runs.

Open source & auditability

BrowserBash is open source under the Apache-2.0 licence. You do not have to take our word for what the CLI does — you can read the code and verify exactly how it handles your pages, credentials, and network calls. The package is published openly on npm:

npmjs.com/package/browserbash-cli — install with npm install -g browserbash-cli (current version v1.3.1).

Responsible disclosure

We welcome reports from security researchers and treat good-faith disclosures as a gift. If you believe you have found a vulnerability, please email thetestingacademy@gmail.com with clear steps to reproduce, the affected URL or command, and any proof-of-concept that helps us understand the issue.

While investigating and reporting, we ask that you:

• Give us reasonable time to fix the issue before any public disclosure.
• Do not access, modify, or exfiltrate other users’ data.
• Do not run denial-of-service attacks, spam, or social-engineering against our users or staff.
• Act in good faith and avoid privacy violations or service disruption.

In return, we will acknowledge your report, keep you updated as we work on a fix, and credit good-faith researchers who report responsibly. Please note there is no paid bug bounty at this time — we recognise researchers with credit rather than cash.

Scope

The following are in scope for responsible disclosure:

• The BrowserBash website at browserbash.com and the cloud dashboard.
• Our APIs used for CLI linking, run upload, and account management.
• The open-source browserbash-cli package itself.

The following are out of scope:

• Vulnerabilities in our third-party providers (Vercel, Clerk, Neon, Vercel Blob, Stripe, Google Analytics) — please report those to the provider directly.
• Issues in the AI model providers you configure (Ollama, OpenRouter, Anthropic), which you choose and contract with directly.
• Reports requiring physical access to a user’s machine, or attacks based on social engineering and outdated browsers.
• Findings with no realistic security impact, such as missing best-practice headers without a demonstrable exploit.

Data deletion

You stay in control of your data. Uploaded free runs are automatically deleted after 15 days. To delete your account or any data you have uploaded at any time, email thetestingacademy@gmail.com and we will remove it. See our Privacy Policy for full details on retention and your rights.

Contact

Security questions, vulnerability reports, or deletion requests? Email thetestingacademy@gmail.com. See also our Privacy Policy and Terms of Service.