Yali Security

The files that should never be reachable, and how to check

7 September 2026 · 6 min read · Web exposure

The most damaging things a scanner finds are rarely vulnerabilities. They are files: a .env with the database password, a .git directory containing the whole source history, a backup.sql somebody left in the web root at two in the morning. No exploit required. They are simply readable.

Why they end up published

Almost always because the web root and the deploy directory are the same directory. git pull on the server leaves .git beside index.php. A framework expects .env one level above the public folder and somebody puts the public folder at the top. A dump taken before a migration never gets deleted.

None of it is visible from the site. There is no link to /.env; you only find it if you ask for it, which is exactly what an automated scanner does all day.

What is worth checking

  • /.env — credentials, API keys, mail passwords.
  • /.git/config and /.git/HEAD — enough to reconstruct the repository, including secrets in earlier commits.
  • /.aws/credentials — cloud keys.
  • Database dumps: .sql, .sql.gz, backup.zip.
  • Editor leftovers: .swp, ~ suffixes, .orig from a merge.
  • /.DS_Store — harmless in itself, and it lists every filename in the directory.

How to validate

Ask for them and read the status code:

curl -sI https://example.com/.env
curl -s https://example.com/.git/HEAD

A 404 is what you want. The answers to look at twice are 200, obviously, and 403 — forbidden means the file is there and something is choosing not to serve it, which is one configuration change away from being served.

Check the body, not just the code. Plenty of sites answer 200 with their own error page, which a status check alone counts as a hit. Our scanner matches the response against the shape each file should have — ref: refs/ for .git/HEAD, KEY=value lines for .env — so a pretty 404 page is not reported as a leak.

Fixing it properly

Blocking the paths at the web server works and is the second-best answer. The first is that the deploy artefact should not contain them: build somewhere else, copy only what is served, and keep secrets in the environment or a secret store rather than in a file next to the code.

If .git was reachable, treat every credential in that repository's history as public and rotate it. Removing the directory does not un-disclose what was already fetched.

How it helps your infrastructure

This is the cheapest exposure to close and the most expensive to leave. Everything else in a scan describes a weakness someone would have to exploit. A readable .env is not a weakness — it is the credentials, already handed over, to whoever asked first.

The Website Scanner requests twenty-five of these paths and checks the content of each response, so a hit means the file, not a status code.

Related reading

Open ports: what an outsider can reach, and why that list mattersOpen, refused and filtered mean three different things. The ports that need a reason, how to see what is listening, and why closing one beats patching it. How to read a URL before you click itRead the host right to left to find the domain that matters, then the five phishing tricks that survive that check. Secure, HttpOnly, SameSite: which cookie flags actually stop an attackEach cookie flag stops a different attack, so setting two is not two thirds of the job. What each one prevents, and how to read your own Set-Cookie header.