Browser Agent Security Risks: CDP Automation Is Leaking Cookies, OAuth Tokens, and Internal App Data

Modern developer workflows and AI copilots increasingly rely on browser automation—Puppeteer, Playwright, Selenium, and now LLM-driven “headless agents” that browse, click, and extract data for you. Most of these tools ride on Chrome DevTools Protocol (CDP) or the evolving WebDriver BiDi. They are powerful. They are also dangerously easy to misconfigure.

Here is the uncomfortable truth: if you hand an agent CDP access to a browser with your real session, you’ve effectively handed it root-equivalent control over your web identity. That means it can read HttpOnly cookies, harvest OAuth tokens, bypass MFA by replaying session state, and even pivot into intranet apps via ambient enterprise single sign-on. In many environments, this risk is no longer hypothetical.

This article explains, in technical terms and with concrete examples, how the attack chains work and what to do about them. It is opinionated: browser automation is not inherently unsafe, but you must architect it with the same rigor you apply to SSH agents, CI runners, and secrets managers.

As always, only test and probe assets you own and are explicitly authorized to assess.

TL;DR

• CDP grants capabilities far beyond the web sandbox, including reading HttpOnly cookies and full network introspection.
• AI copilots and browser agents that connect to a user’s real Chrome/Edge profile can exfiltrate sessions and bypass MFA via session replay.
• If the agent runs on a corporate laptop, it can use your network position and ambient SSO to access intranet resources.
• Defenses: ephemeral profiles, device-bound or sender-constrained tokens (DPoP/mTLS), CDP/WebDriver gating and isolation, strict enterprise policies, egress controls, and auditable automation brokers.

---

1) Why CDP is Different: It’s Not Just "Selenium"

The Chrome DevTools Protocol exposes low-level browser internals so devtools and automation frameworks can:

• Inspect/modify network requests and responses (e.g., Fetch, Network domains)
• Read/modify all storage types (cookies, localStorage, IndexedDB)
• Control targets, pages, frames, inputs, and permissions
• Capture screenshots, DOM, console, performance, and heap snapshots

Unlike JavaScript running in a page, CDP can access HttpOnly cookies via commands such as Network.getAllCookies or Storage.getCookies. It can observe authorization headers, OAuth token responses, and service-worker traffic. WebDriver BiDi is converging on similarly powerful primitives. These are excellent for testing; they are lethal when pointed at a real, logged-in profile.

Two architectural choices push organizations into risk:

1. Connecting to a user’s existing browser via a remote debugging port or pipe, so the agent “borrows” the user’s authenticated state.
2. Running headless browsers with persistent user data directories shared across sessions and tasks, creating long-lived, replayable sessions.

Either approach breaks the implicit security boundary users expect between “my session” and “automation.”

2) The New Automation Stack: LLM Agents Meet CDP

A common pattern today:

• An LLM “copilot” is given a tool that can drive a browser (e.g., Playwright) to accomplish tasks like scraping documentation, testing a staging app, or performing admin tasks.
• To avoid repeated logins and MFA prompts, the tool attaches to an existing browser session or reuses a shared on-disk profile.
• The agent gains the ability to read and emit arbitrary network traffic as “you,” in your corporate context, with your identity and device posture.

This works and is developer-friendly. It’s also the exact path by which sensitive cookies, OAuth tokens, and intranet pages leak into logs, prompts, and third-party toolchains.

Opinion: Treat CDP and WebDriver as security-critical interfaces. If your design gives them access to your primary profile, assume they can exfiltrate all web secrets reachable by that profile.

3) Representative Attack Chains (High-Level)

Below are representative scenarios observed in real environments. They illustrate risk, not instructions to attack.

A) Session Exfiltration via Connected Browser

• A developer runs Chrome with a remote debugging port to allow a local tool to “help with browsing.”
• The agent connects and inspects cookies (including HttpOnly) for domains like your cloud console, CI provider, or CRM.
• It relays cookies or bearer tokens to its backend (e.g., for “context”).
• An attacker who compromises the agent’s backend or intercepts logs replays the session against the target service.

Why it bypasses MFA: MFA protects the issuance of a session. If the agent steals an already-issued session cookie, using it is often indistinguishable from a subsequent, valid request unless the session is sender-constrained.

B) OAuth Token Harvest from SPA

• A headless agent drives a single-page app that stores access tokens in memory and refresh tokens in an IndexedDB store.
• With CDP, the agent subscribes to network events and reads token-bearing responses; it also reads IndexedDB via Storage inspector APIs.
• Tokens are reused off the device (or injected into another headless browser) to access APIs.

This is why standards bodies and vendors recommend httpOnly cookies or sender-constrained tokens rather than localStorage or JS-accessible storage for credentials. But remember: CDP can still read cookies—sender-constraining is what changes the game.

C) Intranet Pivot with Ambient SSO

• On corporate Windows/macOS, browsers often perform ambient Kerberos/NTLM or platform SSO to “intranet” zone services (SSO with no prompt).
• The agent, running on the same machine, navigates internal URLs and receives authenticated responses.
• The agent scrapes internal dashboards and secrets, then exfiltrates them to logs or remote systems.

This is common where AuthServerAllowlist (formerly AuthServerWhitelist) includes wide patterns. It’s convenient for users, and catastrophic when automation shares the same browser posture and network plane.

D) Supply-Chain Assistants with Playwright in CI

• A CI pipeline spins a headless browser to run “visual tests” or “AI triage.”
• The pipeline mounts persistent caches with long-lived cookies or stores Playwright storageState.json artifacts.
• Pipelines from forks or external contributors gain read access to secrets by running the same jobs.

Without strict sandboxing and secret scoping, your CI becomes the exfiltration path.

4) What Doesn’t Actually Help

• HttpOnly, SameSite, Secure flags: Good hygiene, but CDP can still read them. HttpOnly protects against document.cookie, not devtools.
• Headless detection and bot-mitigation: May deter commodity scraping; won’t stop a privileged agent attached to a real browser profile.
• MFA alone: Session replay bypasses MFA once the cookie or token is issued. Use sender-constrained tokens and short TTL with aggressive rotation.
• “We disabled navigator.webdriver”: That only affects naive detection; it doesn’t constrain capabilities.

5) Defenses That Work (Layered)

Security is about reducing blast radius and binding identity to the right device and process.

5.1 Ephemeral Profiles and Isolation

• Do not connect automation to your primary user profile. Ever.
• Launch a dedicated, ephemeral profile per job or task. On Linux/macOS, mount it on tmpfs if possible.
• Never persist Playwright/Puppeteer storageState.json across trust boundaries. Treat it as a secret.

Example: launch Chromium with an ephemeral profile and pipe-based debugging (no TCP port exposure) from Playwright:

ts
// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  use: {
    browserName: 'chromium',
    headless: true,
    // Each worker/process gets a unique, temp context; no sharing of cookies/storage
    storageState: undefined,
  },
  workers: 4,
});

ts
// example.ts
import { chromium } from 'playwright';
import { mkdtempSync } from 'fs';
import { tmpdir } from 'os';
import { join } from 'path';

(async () => {
  const userDataDir = mkdtempSync(join(tmpdir(), 'pw-ud-'));
  const browser = await chromium.launchPersistentContext(userDataDir, {
    headless: true,
    args: ['--remote-debugging-pipe'], // pipe avoids network-exposed port
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  // ... do work ...

  // Ensure teardown wipes the profile directory afterwards
  await browser.close();
  // rm -rf userDataDir in your cleanup routine
})();

Key points:

• Prefer --remote-debugging-pipe instead of a TCP port.
• Use launchPersistentContext with a temp directory that is destroyed at the end of the job.
• Never attach to a long-lived, user-facing Chrome instance for automation.

5.2 Sender-Constrained and Device-Bound Sessions

Replayable bearer tokens are the core problem. Mitigate with cryptographic binding to the client:

• OAuth 2.0 DPoP (Demonstration of Proof of Possession): Binds access tokens to a key pair. Replayed tokens fail without the private key.
• OAuth 2.0 mTLS sender-constrained tokens: Binds tokens to a client certificate.
• WebAuthn/Passkeys for authentication step + short-lived, sender-constrained session cookies.
• Device Bound Session Credentials (DBSC): An emerging standard to bind cookies/sessions to device keys (origin trials exist in Chromium; track the spec status before adopting broadly).
• Refresh Token Rotation and reuse detection; very short lifetimes for access tokens.

These don’t stop a malicious agent on the same device, but they greatly reduce value if tokens are exfiltrated to another host.

5.3 Gate and Broker CDP/WebDriver Access

Treat CDP methods as capabilities you must authorize.

• Don’t expose the remote debugging port beyond localhost. Never bind it to 0.0.0.0.
• Put a broker/proxy in front of CDP that enforces:
  • Allowlist of methods and domains
  • Per-session authn/authz
  • Auditing of high-risk calls (e.g., Network.getAllCookies, Storage.getCookies, Fetch.enable)
• Prefer pipe mode over TCP; if TCP is unavoidable, enforce mTLS at the proxy.

Example: minimal Node.js CDP WebSocket proxy that denies cookie enumeration and logs sensitive methods. This is defensive gating, not a bypass.

ts
// cdp-proxy.ts - a minimal, defensive CDP broker
// Run on localhost and let automation connect to ws://localhost:9223 instead of Chrome directly.
// Chrome must listen on a pipe or localhost TCP port; the proxy enforces policy.

import http from 'http';
import { WebSocketServer, WebSocket } from 'ws';
import { createProxy } from './lib/cdp-proxy-core'; // your implementation

const server = http.createServer();
const wss = new WebSocketServer({ server });

// High-risk CDP methods to deny outright
const denyList = new Set([
  'Network.getAllCookies',
  'Storage.getCookies',
  'Storage.getStorageKeyForFrame',
  'Fetch.enable', // can intercept/modify auth headers
  'Network.setCookie', // session tampering
]);

// Methods that are allowed but logged for audit
const sensitiveList = new Set([
  'Network.getResponseBody',
  'Network.getCookies',
  'Network.enable',
  'Page.printToPDF',
]);

function policyGate(method: string): { allow: boolean; log: boolean } {
  if (denyList.has(method)) return { allow: false, log: true };
  return { allow: true, log: sensitiveList.has(method) };
}

wss.on('connection', (client: WebSocket) => {
  // Authenticate the client (mTLS, token, etc.) before proceeding in real deployments
  const upstream = createProxy('ws://127.0.0.1:9222/devtools/browser/<id>');

  client.on('message', (raw) => {
    try {
      const msg = JSON.parse(String(raw));
      if (msg.method) {
        const { allow, log } = policyGate(msg.method);
        if (log) console.log('[CDP]', msg.method);
        if (!allow) {
          client.send(JSON.stringify({ id: msg.id, error: { code: 403, message: 'Method denied by policy' } }));
          return;
        }
      }
      upstream.send(raw);
    } catch {
      // drop malformed messages
    }
  });

  upstream.on('message', (raw: Buffer) => client.send(raw));
  client.on('close', () => upstream.close());
});

server.listen(9223, '127.0.0.1', () => console.log('CDP proxy on ws://127.0.0.1:9223'));

This is not bulletproof—agents can still do harm via allowed methods—but it raises friction and creates an audit trail.

5.4 Enterprise Browser and OS Policies

Use MDM/group policy to reduce the attack surface. On Chromium-based enterprise browsers (Chrome, Edge), validate policy names and platform support in vendor docs before rollout.

Recommended directions:

• DeveloperToolsAvailability: restrict devtools if not needed in production images.
• ForceEphemeralProfiles: prevent persistent profiles on shared/kiosk/automation hosts.
• IncognitoModeAvailability: restrict if it undermines logging and DLP controls.
• AuthServerAllowlist (formerly AuthServerWhitelist) and AuthNegotiateDelegateAllowlist: tighten to only necessary intranet domains; avoid wide wildcards so ambient auth is not granted broadly.
• URLAllowlist/URLBlocklist: restrict which domains automation hosts can reach.
• ExtensionInstallBlocklist/ForceList: prevent high-risk extensions and force security extensions.
• Enforce local firewall rules: block inbound connections to common CDP ports (9222, etc.).
• Application allowlisting: disallow launching chrome with --remote-debugging-port unless in approved contexts.

For browsers on shared build agents or RPA machines, prefer Chrome Browser Cloud Management or Edge Enterprise management with device trust signals. Where available, leverage device attestation for high-risk apps.

5.5 Network and Egress Controls

• Do not allow headless automation hosts unrestricted egress. Use explicit proxies with authentication and logging.
• Deny direct access to sensitive SaaS unless sourced from ZTNA-protected paths with device posture checks.
• Block inbound CDP/WebDriver ports at the host and network firewalls.
• DLP: monitor for cookie-shaped data and authorization headers leaving your environment.

5.6 Safer LLM-Agent Design

• Use a capability-based architecture: the LLM gets high-level actions ("open url", "extract table") mediated by a policy engine, not raw CDP.
• Domain allowlists and per-task credentials. Never give the agent your primary session.
• Data minimization: redact cookies/tokens from logs and traces by default.
• Human-in-the-loop for risky actions (posting forms, downloading from new domains, accessing admin panels).
• Separate compute and identity planes: the agent runs a clean browser with just-in-time credentials scoped to the task.

5.7 CI/CD Browser Hygiene

• Use containers/VMs with short lifetimes; destroy user data directories at the end of each job.
• Don’t persist Playwright/Puppeteer artifacts that contain storage state across job boundaries.
• Use OIDC federation to clouds and services instead of long-lived service keys.
• Secret scanning in artifacts and logs; block uploads of cookies/tokens.

6) Operational Playbook

6.1 Inventory and Exposure Checks

• Asset inventory: where do we use Playwright/Selenium/Puppeteer? Which jobs attach to a real user browser vs launch their own?
• Process telemetry: log process command lines. Alert on --remote-debugging-port with non-localhost bindings.
• Local exposure check (on your own machine):
  • If you intentionally run remote debugging, ensure it binds to 127.0.0.1 and is firewalled.
  • Accessing http://127.0.0.1:9222/json/version shows the target if enabled. Disable it unless absolutely needed.

6.2 Application-Side Hardening

• Short session TTL; session rotation after sensitive actions.
• Server-side invalidation of session cookies upon logout or suspicious events.
• Audience restrictions and nonce checks in OAuth; PKCE is a must for public clients.
• Move from localStorage tokens to httpOnly cookies with CSRF protections and sender constraints.
• Partitioned cookies (CHIPS) for third-party contexts; limits some cross-site leakage (though not CDP access).

6.3 Monitoring and Detection

• Browser telemetry on endpoints: devtools attach events where available; detect new Chrome processes with debugging flags.
• Proxy logs: unusual bursts of authenticated internal page views from automation hosts.
• CI logs: storageState.json or cookie DB artifacts appearing in artifacts/uploads.
• EDR rules: access to browser cookie databases (SQLite) by unapproved processes; attention to file paths like ~/.config/chromium/Default/Cookies or %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies.

6.4 Incident Response for Suspected Session Leakage

• Invalidate browser sessions server-side. If you don’t have a session revocation mechanism, add one.
• Revoke OAuth tokens; rotate refresh tokens (use rotation with reuse detection).
• Force re-authentication with step-up verification for affected accounts.
• Scope and block the source automation host; collect browser profiles for forensic analysis.
• Review proxy/EDR logs for internal resource access during the window.

7) Practical Launch Patterns and Guardrails

Below are safe(‑r) defaults for automation contexts.

7.1 Chrome/Chromium Launch Flags

• Use --remote-debugging-pipe instead of a port where the framework supports it.
• If a port is necessary:
  • Bind to --remote-debugging-address=127.0.0.1
  • Pick a random high port; firewall inbound traffic.
• Explicit user data dir in a temp directory you control; wipe on exit.
• Disable features not needed for automation to reduce attack surface (e.g., disable extensions).

Example shell wrapper for an automation host:

bash
#!/usr/bin/env bash
set -euo pipefail

TMPDIR=$(mktemp -d)
cleanup() { rm -rf "$TMPDIR"; }
trap cleanup EXIT

# Prefer pipe mode; if your framework requires port, use localhost binding only
chrome \
  --user-data-dir="$TMPDIR/profile" \
  --disable-extensions \
  --headless=new \
  --remote-debugging-pipe \
  about:blank

7.2 Don’t Connect to the User’s Browser

The anti-pattern to avoid is connectOverCDP to a user’s running Chrome. Use a dedicated automation browser. If you must share identity, mint a constrained session for the automation via a backend broker with explicit scoping and expiration.

7.3 Gating High-Risk Domains

For copilots, enforce allowlists. For example, a policy that denies navigation outside *.docs.example.com and *.support.example.com for a doc-scraping task. If access to admin.example.com is ever needed, spin a new task with new credentials scoped to that host.

8) Opinion: Browser Automation Needs Security Baselines Like SSH and CI Runners

We’ve normalized "just connect to Chrome" because it’s convenient. But CDP is a privileged control plane, and conflating it with everyday browsing is an architectural footgun. Vendors should:

• Ship sender-constrained session defaults where feasible.
• Provide first-class, policy-driven CDP/WebDriver brokers with method-level authorization and audit.
• Make it harder to attach to a non-enterprise-managed profile (warnings, policy blocks, attestation).
• Accelerate standards like DBSC that reduce the value of stolen cookies.

Teams should:

• Separate human browsing from automation by default.
• Ban reuse of real profiles for automation.
• Treat storageState, cookies, and CDP access tokens as secrets with lifecycle and rotation.

This isn’t fearmongering; it’s acknowledging that the line between "testing" and "impersonation" disappears at the CDP boundary.

9) Quick Checklist

• Inventory all CDP/WebDriver usage; identify where real user sessions are in scope
• Enforce ephemeral profiles for automation; wipe after each task
• Implement sender-constrained tokens (DPoP/mTLS); shorten token and session lifetimes
• Gate CDP with a broker/proxy; block high-risk methods; audit everything
• Lock down enterprise policies: devtools availability, ambient auth allowlists, URL allow/block
• Firewall CDP ports; prefer --remote-debugging-pipe
• Egress controls and DLP on automation hosts
• Red-team: simulate session replay in authorized test environments; verify defenses

10) References and Further Reading

• Chrome DevTools Protocol docs: https://chromedevtools.github.io/devtools-protocol/
• Chrome remote debugging security note (blog/discussions): guidance to never expose the debugging port publicly (see Chromium project and community posts)
• OAuth 2.0 DPoP (RFC 9449): https://www.rfc-editor.org/rfc/rfc9449
• OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (RFC 8705): https://www.rfc-editor.org/rfc/rfc8705
• OAuth 2.0 Security Best Current Practice (draft/2.1): https://oauth.net/2.1/
• Refresh Token Rotation (Auth0/Okta docs): describes rotation and reuse detection
• CHIPS: Cookies Having Independent Partitioned State: https://developer.chrome.com/docs/privacy-sandbox/chips/
• WebAuthn / Passkeys: https://www.w3.org/TR/webauthn-2/
• Device Bound Session Credentials (DBSC) explainer: search Chromium explainer repo for the latest status
• Microsoft Edge enterprise policies: https://learn.microsoft.com/edge/policies/
• Chrome enterprise policies: https://chromeenterprise.google/policies/

---

If you remember one thing: don’t let automation ride your real browser session. Make sessions ephemeral, sender-constrained, and scoped; run automation in sandboxes; and gate CDP/WebDriver like the powerful control plane it is.