Public Secrets and Configuration Files
NullFault checks whether files like .env, .git, cloud, deployment, and database config are publicly reachable on a production site when they should never be served.
What NullFault Checks
- Whether common mistakes leave files such as .env, .git, source control metadata, cloud config, deployment config, or database config reachable from the public web.
- Whether the response is a real file instead of a normal app page, redirect, login wall, or single-page-app fallback.
- Whether any exposed content contains secret-like values. Evidence is redacted when it looks sensitive.
Why It Matters
- Exposed configuration can reveal infrastructure details, project structure, internal service names, and sometimes live credentials.
- A single leaked private key, service token, or database URL can turn a small deployment mistake into account takeover or data exposure.
- Even non-secret configuration helps an attacker understand how the app is built and where to look next.
Common Causes
- Copying an entire project folder into a public web root, including dotfiles.
- Serving the repository directory without blocking .git and .env paths.
- Build steps that accidentally bundle local config into static output.
Check it yourself
Open your site with paths like /.env or /.git/config in a browser. A real file download or readable text is a red flag; a normal app page or redirect usually is not.
Mitigation
- Remove private files from public build output and static hosting roots.
- Rotate any credential that may have been exposed, even if access logs look quiet.
- Block sensitive dotfiles, config files, package metadata, and deployment files at the CDN, web server, and framework layers.
- On Vercel or Netlify, keep secrets in the platform environment store, not in files that can be bundled or served.
Reality check
This check is intentionally conservative. NullFault tries not to treat normal app fallbacks as exposed files, but you should still open the evidence before assuming impact.