Puppeteer in Docker: pipe transport vs. WebSocket endpoint for avoiding a publicly reachable debugging port

We run Puppeteer inside Docker containers on a shared host, and the current setup launches Chrome with the default WebSocket transport. My concern is the DevTools endpoint: anyone who can reach the debugging port gets full control of the browser, including cookies and page data, with no authentication.

The default binding appears to be loopback-only, but container port publishing (for example a -p 9222:9222 mapping or an overly broad compose ports: entry) could turn that into a network-reachable endpoint. I also see pipe: true documented as an option that connects over stdio file descriptors instead of a TCP port, which would seem to remove the exposure surface entirely.

What I cannot resolve from the docs alone is the practical trade-off. Puppeteer does not appear to enforce or warn about binding scope, so the decision sits entirely with the operator, and I am unsure whether pipe transport has functional or performance limitations compared to the WebSocket transport in containerized workloads.

Specifically: is pipe: true a drop-in replacement for the default transport in Docker, or are there documented cases where it breaks (e.g., browser.wsEndpoint() consumers, remote connections)? If we keep the WebSocket transport, is loopback binding plus unpublished ports considered sufficient, or is an additional control expected? And how should we verify the binding scope across Chrome versions?