Security

Rust’s memory-safety guarantees, explicit error handling, and type system make the implementation of seleniumbase-rs more robust than many dynamic-language alternatives.

This page explains the security properties that Rust provides, the risks that remain, and the operational practices that reduce them.

What Rust gives you#

• Memory safety in safe code: buffer overflows, use-after-free, and data races are ruled out by the compiler for code that does not use unsafe.
• Explicit error handling: Result types make failure paths visible instead of silently propagating None or exceptions.
• Locked dependencies: Cargo.lock records exact dependency versions, making builds reproducible and easier to audit.
• Feature gates: nothing is enabled by default. Optional pieces such as cloud uploads (s3, azure, gcp), Playwright, the MCP server, the terminal UI (tui), native desktop automation (gui) and the embedded database (turso) are compiled in only when explicitly enabled, reducing the default attack surface and dependency tree.
• No unsafe in this crate: the crate’s own source has no unsafe blocks. Its dependencies may.

What Rust does not protect against#

Browser automation is inherently risky because it drives a full browser that can fetch remote resources, execute JavaScript, and read or write files. Even with a Rust harness, the following risks remain:

• Credential exposure: passwords, API keys, and session tokens stored in test code or logs can leak.
• Malicious pages: a test that visits an untrusted URL may download malware, exploit a browser zero-day, or phish the operator.
• Generated code: the Python importer, recorder, and Selenium IDE parser emit Rust code. If the input is attacker-controlled, the output must be reviewed before compilation.
• MCP server access: the sbrs-mcp binary can control the browser and execute JavaScript in any page. An untrusted MCP client can therefore perform any action the browser can.
• Supply-chain attacks: a compromised dependency can still run code at build or runtime, even in a Rust project.

Protections built into the crate#

These reduce some risks; none replaces the guidance below.

• Encrypting secrets: sbrs encrypt and sbrs decrypt (and common::encryption) use AES-256-GCM with a passphrase read from the SB_ENCRYPTION_KEY environment variable, never from an argument, so it stays out of shell history and process listings.
• Passwords out of logs: the Debug output of StealthOptions hides the password in a proxy URL and the values of extra headers, and ProxyEntry never shows a password in Debug or Display.
• Stored profiles: with the turso feature, ProfileVault keeps browser profiles, which hold cookies and proxy passwords, encrypted at rest.
• Untrusted fingerprint payloads: switches that run a program, load code, open remote debugging, or redirect traffic (for example --renderer-cmd-prefix, --load-extension, --remote-debugging-port, --proxy-server) are refused when they come from a fingerprint payload.
• Confined output: artifacts such as screenshots and recordings are written into latest_logs, and a file name with a directory part or .. is refused. MCP file-writing tools are confined to SB_MCP_OUTPUT_DIR (default ./mcp_output), and absolute paths and .. are refused there too.
• Closing browsers: sbrs and sbrs-mcp close their browser on SIGINT and SIGTERM, within SB_SHUTDOWN_TIMEOUT_SECS, so an orchestrated stop does not leave a logged-in browser running.

Secure operating guidance#

Credentials and secrets#

• Keep credentials in environment variables, a secrets manager, or your CI provider’s secret store. Never commit them to source control.
• Use dedicated test accounts with the least privilege necessary.
• Rotate test credentials regularly and audit who has access to them.

Untrusted input#

• Treat page content, downloaded files, generated selectors, imported Python code, and recorded actions as untrusted input.
• Review generated Rust files from sbrs import-python or the recorder before compiling or running them.
• Do not run generated tests against production-like data or credentials until you have inspected them.

MCP server#

• Build the sbrs-mcp binary only when needed and distribute it only to trusted hosts.
• Consider running the MCP server in a sandbox or container with limited network access.

Dependency auditing#

• Run cargo audit or cargo deny check in CI to detect known vulnerabilities in dependencies. This repository’s CI runs cargo deny check with the deny.toml at the repository root, which also bans wildcard version requirements and unknown registries and git sources, checks licenses, and lists each ignored advisory with the reason.
• Review Cargo.lock changes in pull requests, especially for optional features that pull in large dependency trees.
• The crate has no git dependencies. If you add one, pin it to a specific tag or revision (and allow it in deny.toml).

Isolation#

• Run tests that visit untrusted pages in disposable containers, virtual machines, or CI workers that are reset after each run.
• Do not run the browser as root or with unnecessary privileges.
• Use headless mode in CI, but remember that headless mode is not a security boundary by itself.

Stealth mode limitations#

Threat model summary#

Security checklist for new projects#

• Credentials are loaded from environment variables or a secrets manager.
• Test accounts have minimal permissions.
• cargo audit runs in CI.
• Generated Rust is reviewed before execution.
• MCP server is restricted to trusted clients.
• Untrusted-page tests run in isolated environments.
• The team understands that stealth modes are not security controls.

Related reading#