Private files are being served publicly
Some files are usually kept private: a .env often holds secrets, and a .git folder holds your code history. A misconfigured host or a bad deploy can serve them publicly. Here is what it means, why it happens, and how to fix it, including the step people forget.
What it means
A file that is usually kept private, like your .env (which often holds secrets) or a file from your .git folder, is served from your live site. What it contains decides how serious that is.
Why AI tools cause it
A misconfigured host or a bad deploy can expose these. AI setups sometimes deploy the whole project folder, including files that should be ignored.
How xlogs checks it
xlogs makes a read-only request for a small set of paths where sensitive files are often left (.env, .git/config), and grades each file by what it contains.
Check your own app for this
How to fix it
The goal: Private files (.env, .git) are not downloadable from the live site, and every secret that was in an exposed .env has been replaced and the exposed value revoked.
- Contain it: stop the host from serving the affected spot (fix the host config and .gitignore, and keep it out of the deploy output)
- Rotate every secret that was in the exposed file, because removing the file does not stop those values working: revoke at once if you suspect misuse; otherwise create replacements, update the app's secret settings, confirm the app works, and then revoke the exposed values promptly
In my app (the spot the scan shows): private files are being served publicly. Please make this true: Private files (.env, .git) are not downloadable from the live site, and every secret that was in an exposed .env has been replaced and the exposed value revoked. Steps: Contain it: stop the host from serving the spot the scan shows (fix the host config and .gitignore, and keep it out of the deploy output); Rotate every secret that was in the exposed file, because removing the file does not stop those values working: revoke at once if you suspect misuse; otherwise create replacements, update the app's secret settings, confirm the app works, and then revoke the exposed values promptly. Then tell me exactly what you changed, and do not print any secret values back to me or write one into a commit message, a pull request description or a log.
Then verify: After the fix, xlogs requests the file again and reports whether it is still served.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
How serious is an exposed .env or .git folder?
It depends on what the file shows. A served .env that holds a credential, or a .git file whose remote carries a login or a token, is critical: it hands the secret over, and a served .git folder can let someone download your source history, including secrets you committed and later removed, which xlogs does not test. A .env of settings with no credential in it, or a single .git file, is graded lower, but the folder that holds it is public, so fix it either way. None of this needs hacking, just a direct request.
I stopped serving the file. Am I done?
Not quite. If a .env was exposed, assume every secret in it is compromised and rotate them (regenerate them at each provider). Removing the file stops new leaks; rotating the keys closes the ones that already leaked. Then re-scan to confirm the file is no longer public.