exposed-developer-and-debug-endpoints

While inspecting how the frontend communicates with the backend, I noticed that API calls were being made to a server hosted on port 80. Out of curiosity, I accessed the same port directly through my browser to see if it was publicly exposed. To my surprise, the server responded — albeit initially with a generic “File Not Found” message.

This prompted me to dig deeper. I began exploring common developer and debug endpoints and quickly discovered several critical exposures. Notably, the backend was serving a publicly accessible phpinfo() page, a classic misconfiguration that reveals detailed environment information, including PHP version, loaded extensions, configuration directives, and even partial server paths.

Even more concerning, the Dockerfile used to build the application environment was also accessible via HTTP. This file often contains sensitive build instructions, environment variables, internal service names, and possibly even secrets if not handled properly. Exposure of such internal build artifacts drastically lowers the effort required for an attacker to replicate, reverse engineer, or exploit the environment.

This kind of exposure is a textbook example of Security Misconfiguration (OWASP A6). Development and debug endpoints should never be accessible in a production environment. They serve no purpose to end-users and only increase the attack surface, offering insight into the underlying stack and infrastructure that can be weaponized during an attack.

This is a Medium to High severity issue (CVSS ~6.5) because it leaks sensitive system and environment information that can facilitate further attacks.

As a remedy, we should:

• Remove or restrict access to all developer/debug endpoints like phpinfo() and Dockerfiles in production.
• Use network controls, authentication, or IP whitelisting for such pages if absolutely necessary.
• Adopt secure deployment practices to avoid exposing internal files and disable verbose error/debug output.