An HTTP Intercepting Proxy with Chrome DevTools Protocol (CDP)

by

Author: Denis Andzakovic
Published: July 29, 2026
Source: https://pulsesecurity.co.nz/articles/glorp-cdp-support

Summary

Pulse Security’s Denis Andzakovic describes a new logging mode added to Glorp, an open-source HTTP intercepting proxy, that captures browser traffic using the Chrome DevTools Protocol (CDP) instead of a traditional man-in-the-middle setup. Rather than terminating TLS via an HTTP CONNECT tunnel and a trusted CA certificate, the tool attaches to a browser over CDP’s WebSocket interface and reads the HTTP data the browser generates natively. This is a tooling/technique writeup rather than a vulnerability disclosure — no CVE is assigned and no specific product vulnerability is claimed.

Technical Details

CDP is the protocol that backs Chrome DevTools, exposing browser internals over a WebSocket. Glorp connects to that WebSocket — reached by launching the browser with --remote-debugging-port=9222 — and consumes request/response data directly from the browser instead of intercepting it on the wire. Because the data is taken after the browser has already assembled and (for TLS) decrypted it, the approach captures HTTP/1.1, HTTP/2, HTTP/3, and WebSocket traffic uniformly and requires no CA installation or TLS termination. The article discusses the concept at a high level and demonstrates it in embedded videos; it does not enumerate the specific CDP domains/events used (for example the Network events that carry request data), and the author notes the technique is limited to browsers that support CDP, suggesting WebDriver BiDi as a possible next step.

Impact

For security testing, capturing traffic from inside the browser sidesteps client TLS fingerprinting (such as JA4): requests originate from the genuine browser stack, so they are not distinguishable by the fingerprint a separate proxy would present. The same primitive underlies a broader offensive use the author references from prior Pulse Security work — an exposed or attacker-reachable remote debugging port lets a third party attach over CDP and log or drive another user’s browser session. The article frames this as capability/tradecraft for testers, not as a new exploit, and reports no affected-version list because there is no vulnerability being disclosed here.

Mitigation

The article notes that modern Chrome and Microsoft Edge, from release 150 onward, no longer honor the --remote-debugging-port flag when the default --user-data-dir is in use, which blocks the simplest path to attaching CDP against a user’s normal browser profile. The author also points to upcoming DevTools/MCP work adding user notifications and visible indicators when remote debugging is active. General guidance that follows: do not expose remote debugging ports, and treat any process able to reach a browser’s CDP endpoint as having full access to that browser’s sessions.

References

Leave a Comment