Exposed .env and other files that should never be public
A `.env` file holds the database URL, API keys and session secrets of your app. If your server hands it out to anyone who asks for `/.env`, every one of those secrets is gone. It happens more often than it should, especially with servers set up by an AI agent.
Verified Runs after you verify your domain. Verification is free on every plan.
What it is
Frameworks read .env from the project root at startup. The file is not meant to leave the server. It becomes public when the web server serves the project root as static files, when a build copies it into the output folder, or when the whole folder is uploaded to a host that serves everything. The same mistake exposes .git/config and .git/HEAD, which can let someone rebuild your source code history, and backup files like backup.sql.
What can happen
Exposed .env files are found by automated scanners within hours, because asking for /.env costs nothing. With the database URL, an attacker connects directly to your database. With the payment, email or AI keys, they use your accounts. With the session secret, they can forge logins. Unlike a key in a bundle, which is usually one key, an .env file is often all of them at once.
How Shypset checks it
This is a Verified check. Requesting paths your page never links to is something a normal browser does not do, so we run it only for domains you have verified. We request a fixed list of about 35 paths, among them:
/.env,/.env.local,/.env.production,/.env.backup,/.env.old/.git/config,/.git/HEAD,/.svn/entries/backup.sql,/dump.sql,/database.sql,/config.yml/.aws/credentials,/.npmrc,/docker-compose.yml,/server.js/phpinfo.php,/phpmyadmin/,/adminer.php
Single-page apps answer every path with their index.html, so an HTML page or a not-found response is not counted as an exposed file. For a file that answers we keep the URL, status, size and, for config files, only the names of the keys inside, such as DATABASE_URL. Values are never stored or shown.
How to fix it
- Rotate every secret in the file. You cannot know who downloaded it.
- Serve static files only from the build output folder, never from the project root.
- Add a rule at your host or server that returns 404 for any path starting with a dot.
- Keep
.envin.gitignoreand out of your deploy artifact; use your host’s environment variable settings instead. - Rescan to confirm the path now returns 404.
Example finding
How the finding appears in a report, with its fix prompt.
Evidence
URL: https://app.example.com/.env HTTP status: 200 Size: 286 bytes Keys: DATABASE_URL, STRIPE_SECRET_KEY, JWT_SECRET
Fix prompt
Our server returns the .env file at /.env. I am rotating DATABASE_URL, STRIPE_SECRET_KEY and JWT_SECRET now. Change the server so it serves static files only from the build output folder, return 404 for every path that starts with a dot, make sure .env is excluded from the deploy, and read secrets from the host’s environment variables.
Questions
- My app is on Vercel or Netlify. Can this happen?
- It is rare there because only the build output is served, but a build that copies .env into the output still exposes it.
- Why is this check not in the free anonymous scan?
- It probes paths the site does not link to, so we run it only after the owner verifies the domain. Verification is free.
Check for exposed files
Scan your site from the home page, then verify your domain to run the file checks.
Scan your site