CWE-531, Inclusion of Sensitive Information in Test Code, covers test applications that end up reachable by people who were never meant to see them. MITRE's point is blunt: developers and administrators rarely imagine anyone but themselves knows these apps exist, so they tend to hold sensitive information or functions.
How it happens
A team builds a quick test page to check a database connection or exercise an admin function. It uses real credentials because that is the fastest way to see it work. The page ships with the rest of the build, or sits on the server after a debugging session.
Nobody links to it, so it feels hidden. But hidden is not protected. Scanners and curious visitors request common test paths all day.
What an attacker gains
MITRE lists a confidentiality consequence: the attacker can read application data. Test code often contains hardcoded accounts, connection strings or verbose output that would never pass review in production code.
How to find it
- List what is actually deployed and compare it with what should be. Test folders and sample pages stand out.
- Search the codebase for words like
test,debug,sampleanddemoin route definitions and web directories. - Scan the repository for credentials in test fixtures. A secrets scan catches the obvious ones.
- Request your own production URLs for common test paths and see what answers.
How to fix it
MITRE's guidance is short: remove test code before deploying the application into production.
- Keep test code in a separate directory that the production build never packages.
- Make the build fail if known test paths appear in the artifact.
- Use fake credentials in tests, never real ones.
- Review the deployed file list during release, not only the diff.
Quick check
If a test page is not linked anywhere, is it safe?
No. Unlinked does not mean unreachable. Anyone who guesses or finds the path can request it, so the page must not be deployed.
