phpinfo.php, server-status, .DS_Store: the small leaks that map your server

Not every exposed file is a five-alarm fire. Some don't leak a single credential. They leak knowledge: the exact version of everything you run, the paths on your disk, the modules you loaded, the files in a folder you never linked. On their own each one is a shrug. Together they're a finished reconnaissance report, and you wrote it for the attacker.

These are the low-severity files SurfaceCheckr flags not because one of them sinks you, but because they remove all the guesswork from whoever's deciding how to come at you.

What each one tells a stranger

The value of these files is that they turn "probe and guess" into "look it up." An attacker who knows your precise PHP version doesn't fuzz for vulnerabilities; they search a CVE database for that exact version and arrive with the right exploit.

The phpinfo.php page is the richest of the set. It's a diagnostic page that prints everything about the PHP runtime, and developers drop one in to check a setting and forget to delete it. It hands over the version (so the attacker knows which exploits apply), the absolute paths (so they know where things live on disk), the loaded extensions (so they know what's attackable), and the environment (which sometimes includes values that were never meant to be public).

Why a long list of small leaks matters

The mistake is treating each of these as individually harmless and therefore ignorable. Attackers don't read them individually. They aggregate.

The .DS_Store leak is the clean illustration. macOS writes a hidden .DS_Store file in every folder to remember the icon layout, and it contains the names of the files in that folder. Deploy from a Mac without excluding it, and now a stranger can read .DS_Store and learn the names of files you never linked: admin-backup.zip, old_database.sql, notes-internal.txt. They didn't have to guess those filenames. You listed them. Same story with package.json: it names every library and version you depend on, which is the input to "which of these has a published vulnerability." This is the file-leak version of tech-stack fingerprinting from your headers: the more precisely your stack is known, the shorter the attacker's research phase.

The fix is deletion and a deny rule

These files mostly shouldn't exist in production or shouldn't be deployed. The diagnostic ones (phpinfo.php) get deleted. The accidental ones (.DS_Store, Dockerfile, package.json in the served root) get excluded from the deploy. The server features (/server-status) get restricted to localhost.

# phpinfo.php left in the web root after debugging
# .DS_Store deployed from a Mac
# Apache server-status open to the world
<Location /server-status>
SetHandler server-status
</Location>

For the static files that keep sneaking in, a server-level deny on dotfiles and known leak-prone names is the backstop, and a .gitignore/deploy-exclude list is the real fix. Quiet your Server and X-Powered-By headers while you're at it, since they leak the same version information from a different angle.

None of these will hard-fail your grade, and we don't pretend they're critical. But they're all readable from outside, so we check for them. SurfaceCheckr requests the known diagnostic and metadata paths and confirms each response is the real file before flagging it, so you get an accurate list rather than soft-404 noise. We can't tell you whether an attacker has already used this map, only that it's lying there for them to read. Cleaning it up is the cheap, boring hygiene that makes you a slower, more annoying target, which is most of what passive hardening is.