Is your .env file exposed to the internet?
A misconfigured server can hand your .env file — database passwords, API keys, app secrets — to anyone who asks for it. Enter your site and DotenvScan checks from the outside, the same way an attacker would.
The files that leak secrets.
Backup and editor copies (.env.bak, .env.save, .env.old) are the usual culprits: the app ignores them, but the web server sends them as plain text to anyone who requests them.
- 01/.env
The main environment file. It usually holds database passwords, API keys and app secrets.
How to fix - 02/.env.production
Production environment file — the live credentials.
How to fix - 03/.env.local
Local overrides, often copied to the server by mistake.
How to fix - 04/.env.bak
A backup copy. The app ignores it, but the web server will serve it as plain text.
How to fix - 05/.env.save
An editor save file (e.g. from nano). Served as plain text.
How to fix - 06/.env.old
An old copy left behind after an edit. Served as plain text.
How to fix - 07/api/.env
An API deployed in a subfolder of the site, with its own .env beside it.
How to fix - 08/backend/.env
A back end uploaded into the web root next to the front end, .env included.
How to fix - 09/wp-config.php
WordPress’s live config. PHP normally runs it and sends back nothing — but if PHP stops handling it (a broken upgrade or server move), the server sends the source, passwords and all.
How to fix - 10/wp-config.php.bak
A backup of WordPress config. PHP runs wp-config.php, but sends the .bak as plain text — database credentials and secret keys.
How to fix - 11/phpinfo.php
A leftover test page that prints PHP’s whole configuration — server paths, request headers and the environment variables where secrets often live.
How to fix - 12/info.php
The same phpinfo() test page under its other common name.
How to fix - 13/storage/logs/laravel.log
Laravel’s log, reachable when the web root is the project folder. Errors in it often carry queries, tokens and stack traces.
How to fix - 14/.git/config
An exposed .git directory can leak your whole source code and its history, including secrets committed in the past.
How to fix - 15/.svn/wc.db
Subversion’s working-copy database. Like an open .git, it lets anyone list and download your source files.
How to fix - 16/.aws/credentials
AWS access keys from a home or project folder that ended up inside the web root.
How to fix - 17/.DS_Store
A macOS folder index uploaded with the site. It lists file and folder names, pointing attackers at backups and hidden files.
How to fix
An outside-in check, in seconds.
You enter your address
Just the domain, like example.com. We scan it over HTTPS.
We request each path
A plain GET for /.env and the others — exactly what a browser or a bot would do. Nothing is changed on your server.
You get a verdict
For each file: exposed, protected, or not found. We read only enough to tell a real file from an error page, and never store it.
Prefer the command line? The manual check is curl -sI https://example.com/.env — look for 403 or 404, not 200. DotenvScan runs that check for every path at once and reads the result for you.
$ curl -sI https://example.com/.env
One exposed file is a full breach.
An exposed .env typically contains everything an attacker needs at once: database credentials, cloud and payment API keys, mail passwords and app secret keys. Automated bots request /.env on millions of sites a day, so exposure is usually found in hours, not years.
- Database username and password
- Cloud, payment and email API keys
- App secret / signing keys (session, JWT)
- Everything needed to impersonate your app
Found one? There are usually more.
DotenvScan checks a site from the outside. To find every secret file across a whole server — all hosting accounts, backup copies, WordPress, Laravel, Magento and more — run ServerSecretVault on the server itself. It's read-only, makes no network requests, and rates each file's risk.
$ curl -fsSL serversecretvault.com/install.sh | sudo sh
Found something? Fix it properly.
Step-by-step fixes for the files DotenvScan checks, with web-server rules tested on real nginx, Apache and Caddy servers. All guides
Your .env file is exposed. Here’s what to do now.
Block it in nginx, Apache or Caddy, rotate every secret in it, check your logs, and move it out of the web root.
What is a .env file? And why it must never be public.
What goes in a .env file, how frameworks load it, the four ways it ends up public, and how to keep it private.
Your wp-config.php backup is public. Here’s how to fix it.
A .bak or .save copy of wp-config.php gives away the database password and keys. Block it, change them, check for intruders.
Laravel .env exposed: fix it, and rotate APP_KEY safely.
Point the web root at public/, rotate in the right order, change APP_KEY without breaking encrypted data, and turn off debug mode.
An exposed .git directory gives away your source code.
If /.git/ is reachable, your code, history and old secrets can be rebuilt. Check it, block it, rotate, and deploy without it.
A public phpinfo() page gives away your server’s secrets.
A leftover phpinfo() test page prints server paths, request headers and environment variables. Remove it, disable it, rotate.
Other dotfiles that leak: .aws/credentials, .svn and .DS_Store.
AWS keys, Subversion working copies and macOS .DS_Store files in the web root: what each leaks, and one rule for all of them.
NEXT_PUBLIC_ and VITE_ variables are public. Keep secrets out of them.
Front-end tools ship NEXT_PUBLIC_, VITE_ and similar variables to every visitor. What is safe, and how to check your bundle.
Questions.
What does DotenvScan check?
It requests a short, fixed list of config-file paths on the address you enter — .env and its backup copies, WordPress’s wp-config.php and its .bak copy, leftover phpinfo() pages, Laravel’s log, and the .git, .svn, .aws and .DS_Store dotfiles — and reports whether each one is downloadable. It only makes GET requests, and only to the one site you enter.
Does it show or store my secrets?
No. For each path it reads only enough of the response to tell a real config file from an ordinary "not found" web page, then discards it. It never displays, logs or stores the contents, and it doesn't keep your scan results.
Is it safe to run against my own site?
Yes. Every request is a plain GET, the same as a browser loading a URL. It changes nothing on your server. It won't scan internal or private addresses, only public websites.
It says a file is exposed. What do I do?
Treat the secrets in that file as compromised: rotate the database password, API keys and any app secret keys. Then remove the file from the web root or block it in your web server, and check your access logs to see if it was already downloaded. The exposed .env guide walks through it, with copy-paste rules for nginx, Apache and Caddy.
Why only my homepage address — can it scan every page?
Exposed config files sit at known paths, so a fixed short list catches them without crawling your whole site. Keeping the list fixed is also what stops the tool being turned into a general-purpose scanner.
I run WordPress. What else should I do?
If wp-config.php or a copy of it was exposed, follow the wp-config backup guide: change the database password and replace the keys and salts — the WPSalt salts generator makes fresh ones in your browser. For a wider check of the site, WP Server Guard does WordPress security audits and malware cleanup.
I have lots of sites on one server.
Checking them one address at a time from outside is slow. ServerSecretVault runs on the server itself and finds every .env, wp-config.php and backup across all accounts in one pass, then rates the risk.