I can agree with that with the caveat that "enabled" has to be at either something that only the user can do. If it requires that the customer intentionally run a debug build, that's fine; if it can be toggled on without their knowledge, then it's a problem.

It was disabled by default, and could only be enabled using environment variables. Even when enabled, the whole thing ran in Docker and the socket was bound to loopback, so you could only connect to it from within the container.

When the intention is a debugging server, making it exposed to the world is a mistake and a security vulnerability. At that point it is effectively a backdoor, but the difference between a high level vulnerability such as this and a backdoor is developer intent.

That doesn't sound very safe.

What sounds unsafe about having a locally bound port inside a container that only binds with an env variable getting set?

For example that someone finds out about that backdoor and activate it to spy on users. Forwarding a port in Docker is not magic…

Sure, it's simple. But you would have to be able to modify the container settings anyway. For all practical uses, and certainly in my case, you could just make it run a different image at that point. Or copy another executable into the container and run it. You're already privileged. Requiring you to be privileged to access the debug server means it's secure.

Until things around change and what was previously "a secure backdoor" becomes a "less secure backdoor". ;-)

One can read every second week about cases where some backdoor that was meant to be used "only for debugging" landed in the end product and became a security problem.

Actually I usually suspect malice when something like that is found once again, as "who the hell could be so stupid to deliver a product with a glaring backdoor". But maybe there is something to Hanlon's razor… :-D

If you're already running another process in the container, you could do whatever you want anyway.