How to Secure an Unprotected Selenium Grid

If a Selenium Grid is reachable by people or systems outside its intended trust boundary, first restrict network access. Then configure the authentication, HTTPS, and Node registration controls supported by your Selenium version, and verify the result from both trusted and untrusted networks. A password alone does not replace network isolation.

Selenium warns that Grid must be protected from external access with appropriate firewall permissions. An exposed Grid can let outsiders use its infrastructure, reach internal web applications and files, or run custom binaries. Selenium Grid getting started documentation

1. Contain the exposure first

Identify every route to the Grid. Check the host bind address, container port publishing, Kubernetes Services and Ingress, cloud firewalls or security groups, load balancers, and reverse proxies. A service configured to listen on localhost may still be exposed through a published port or proxy.
Restrict the user-facing endpoint. Allow only trusted test clients to reach the endpoint used to create sessions and, if needed, load the Grid UI. Deny unsolicited traffic from the public internet and other untrusted networks.
Keep component traffic internal. Permit only the communication required between Grid components. Do not publish internal component ports publicly just because components need to communicate.
Check for alternate paths. Review old port mappings, temporary ingress rules, and direct Node addresses so an attacker cannot bypass the intended entry point.

Selenium documents http://localhost:4444 as the default Standalone RemoteWebDriver address. That default does not prove a deployed service is private: inspect the actual listener and every network layer in front of it. Distributed Grid setups also need component communication. Selenium’s getting-started material lists Event Bus ports 4442, 4443, and 5557, and Session Queue port 5559; treat these as topology context, not a complete firewall policy. Confirm the flags and required flows for your deployment. Grid setup and port documentation

2. Identify your Grid mode and version

Before changing configuration, record whether the deployment is Standalone, Hub/Node, or fully distributed; which host and port clients use; which components communicate; and the Selenium Server version. These details determine which controls and network rules apply.

Run the security help command using the deployed server artifact:

java -jar selenium-server-<version>.jar info security

Use the output to confirm the security options available in that exact version. Selenium says configuration help reflects the current implementation and is the best way to check an option when documentation may have changed. Selenium configuration help

Version is material. Selenium’s July 2024 SeleniumGreed post reported abuse through session creation, noted that Grid has no authentication by default, and urged operators to upgrade because security items had been added since older versions. Treat that as dated threat context, not proof that upgrading alone fixes an exposed deployment. Check the current release and compatibility before upgrading. Selenium’s SeleniumGreed security post · Selenium downloads

3. Configure authentication and secure communication

Basic authentication

Selenium documents username and password configuration for the Router. The credential pair is required to load the Grid UI or start a new session. The exact TOML structure and supported flags can vary by version, so validate against info security and the configuration reference for the deployed release.

# Example fragment for a Selenium Grid TOML configuration.
# Confirm the exact section and option names with your deployed version.
[router]
username = "grid-user"
password = "replace-with-a-secret-from-your-secret-store"

Supply the values through your deployment’s secret management mechanism where possible. Do not commit credentials to source control, expose them in public documentation, or print them in logs. Plan how to rotate them and update authorized clients.

HTTPS

The Selenium CLI reference lists --https-certificate and --https-private-key for HTTPS configuration. You can terminate TLS in Selenium or at a trusted proxy, depending on your architecture. Protect the client-to-entrypoint connection; assess and protect the proxy-to-Grid connection according to the threat model for that network segment.

java -jar selenium-server-<version>.jar standalone \
  --https-certificate /path/to/certificate.pem \
  --https-private-key /path/to/private-key.pem

This is a command shape, not a complete deployment recipe. Confirm that the options and invocation match your version, certificate format, Grid mode, and secret handling. Selenium CLI options

Node registration secret

For Hub/Node or applicable distributed configurations, Selenium documents --registration-secret as a shared secret used to authenticate Node registration requests. Its value must match on the Hub or Distributor and the registering Node, as applicable to the version and topology. Store it as a secret and restrict registration and control traffic to trusted components.

java -jar selenium-server-<version>.jar node \
  --registration-secret "$GRID_REGISTRATION_SECRET"

Set the secret in the runtime environment through your deployment’s secret mechanism. Confirm the exact command and which components need the value in the deployed version’s security help. Do not paste the secret into shell history or a shared terminal transcript.

4. Verify the security boundary

From an untrusted network, confirm the user-facing endpoint and management or component ports cannot be reached.
From an authorized client, confirm the expected authentication and HTTPS behavior, and verify that a new session can be created.
For a distributed Grid, confirm the required component flows still work and registration is protected by the configured secret.
Review cloud and network policies, proxy routes, container mappings, and Kubernetes exposure to ensure a later deployment change has not reopened access.
Record the Grid mode, version, entrypoint, permitted clients, component flows, TLS termination point, and secret rotation process.

These checks follow from Selenium’s documented exposure risks and configuration controls. They are a verification procedure, not a claim that a particular Grid was tested.

Common problems and fixes

Symptom	Likely cause	What to check or fix
Grid still responds from the internet after binding to localhost	A container port, load balancer, ingress, or proxy still exposes it.	Trace the full network path and remove or restrict each public route; verify from an external network.
Clients cannot create sessions after enabling authentication	The client or UI request is missing credentials, or the configuration section/options do not match the deployed version.	Check the version’s security help, Router configuration, and client authentication setup. Keep credentials out of logs while debugging.
Grid UI or session creation fails after enabling HTTPS	Certificate or private-key path, format, permissions, or TLS termination settings are incorrect.	Validate the paths and formats, confirm the process can read the files, and check which hop terminates TLS.
Nodes fail to register	The registration secret differs, is missing on a required component, or the registration path is blocked.	Compare secret injection on the relevant components and allow only the required internal registration flow.
Components stop communicating after firewall changes	A necessary internal flow was blocked or the assumed ports do not match the actual topology.	Inspect the deployed configuration and logs, then permit only the specific required component-to-component traffic.
Documented option is rejected by the server	Documentation and deployed artifact differ, or the option is unavailable in that version or mode.	Run `info security` and check that release’s configuration help before applying a change.

Performance, reliability, and operating cost

Network restrictions and authentication add policy and credential management, but the research sources provide no benchmark for their performance impact. Validate session creation and component communication in a representative environment after each security change. TLS also requires certificate lifecycle management. Budget operational effort for secret storage and rotation, version upgrades, network policy review, and compatibility checks.

A self-hosted Grid gives the team responsibility for its network boundary, server version, and configuration. A managed browser-testing service may be an option if the team cannot operate that infrastructure, but evaluate its access controls, browser coverage, and operational terms directly; the sources do not establish or endorse a particular provider.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It captures website screenshots or PDFs; it does not secure or replace a Selenium Grid. For screenshot work, one GET request can return an image or PDF. The API can accept a cookie banner like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, with the result indicated by response headers. AI agents can use its MCP server and the take_screenshot, get_page_info, and capture_pdf tools. Plans include 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000. Learn about ScreenshotNeo.

For example, capture a public page with cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Equivalent Python request:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Equivalent Node.js request:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

See the ScreenshotNeo API documentation for request options. Sign up for 1,000 free screenshots a month with no card.

FAQ

Does Selenium Grid have authentication by default?

No. Selenium’s security guidance says default Grid authentication is absent; configure the controls supported by your deployed version and restrict network reachability.

Is a password enough if Grid is not publicly advertised?

No. A reachable service can still be discovered. Apply network restrictions at the actual ingress and component paths, then add authentication and secure communication.

Which firewall ports should I open?

There is no universal rule set in the cited documentation. Start from your Grid mode and actual configuration; allow the client entrypoint and only the internal component flows that deployment requires.

Will upgrading alone secure an exposed Grid?

No. Upgrade and configure applicable security controls, but retain network isolation and verify the result.

Does ScreenshotNeo replace Selenium Grid?

No. ScreenshotNeo captures website images and PDFs through an API or MCP server. It is an alternative for screenshot capture workflows, not a Grid security control or WebDriver replacement.