lightpanda-io / lightpanda-io/browser

CDP endpoint has no authentication option — any local process can drive an agent's authenticated session

Open
#3,452 1 comment 0 reactions 1 assignee View on GitHub

@krichprollsch is already working on this.

Since Sep 9, 2026.

Dominant language
Zig
Stars
35.5k
Forks
1.7k
Avg merge
21h 13m
Merged PRs (30d)
262

Description

Problem

Lightpanda's CDP endpoint (ws://host:9222/... + http://host:9222/json/*) accepts any local connection with no authentication. The only gate today is the Origin header check on the WebSocket handshake, which is trivially bypassed by non-browser processes (any Python/Node script, curl with suppress_origin, etc.).

This matters a lot for agents: for a tool that feeds a browser runtime carrying real user credentials (cookies, OAuth sessions), an unauthenticated loopback CDP port means every local process on the host can drive the authenticated session — navigate, evaluate JS, read cookies, exfiltrate tokens. On shared/agent hosts that population includes the agent's own subprocesses and anything it was instructed to run.

By contrast, a real Chrome instance behind --remote-debugging-port is at least commonly paired with a dedicated profile and firewall assumptions; and Puppeteer's own devtools endpoint supports --remote-allow-origins. For an "AI agents" browser whose advertised use is autonomous runs, the blast radius is bigger.

Requested

Any of these would be a big win:

  1. --cdp-token / LIGHTPANDA_CDP_TOKEN env var — when set, every HTTP and WS request must carry Authorization: Bearer <token> (WS: ?token= query param since browsers can't set WS headers — or Sec-WebSocket-Protocol trick).
  2. Strict-by-default Origin allowlist: reject WS upgrades whose Origin is not in a configured allowlist, instead of the current permissive check; allow null/chrome-extension:// only when explicitly enabled.
  3. Bind-confirmation log: print a loud warning at startup when the listener is reachable beyond loopback.

Workaround we use today

Lightpanda Session Bridge (community tool) puts a token-authenticated localhost relay (X-Bridge-Token, 127.0.0.1 only) in front of the CDP port for agents — but it's a relay, not a real fix: anything that can reach port 9222 directly still bypasses all of it. Native auth in Lightpanda would make the boundary actually hold.

Happy to test a beta build or a PR draft.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.