Exposed .env files and leaked API keys: how to check your site and what to do next

Open a new browser tab, type your site's address, and add /.env on the end. If anything other than a "not found" page comes back, stop reading and go to the section on what to do. If it's clean, keep reading, because that one URL is only the start.

A .env file is where many projects keep their private settings: database passwords, payment keys, email credentials, tokens for other services. It's meant to live on your server and nowhere else. When it ends up somewhere the public can reach, anyone can read it, and no hacking is required.

How secrets end up in public

It's rarely carelessness in the dramatic sense. It's almost always a small setup choice that nobody revisited.

• The web server points at the project folder instead of a dedicated public folder, so every file inside is downloadable.
• A key gets committed to a repository for a quick test, then deleted in the next commit. The history still remembers it.
• A backup or staging copy is left online, such as backup.zip, site-old/ or dev.yoursite.com, often with a full copy of the configuration.
• Debug tools stay switched on, like a phpinfo.php page or a log file such as storage/logs/laravel.log that prints settings and stack traces.
• Secrets are baked into the front end. In Next.js, any variable starting with NEXT_PUBLIC_ is written into the JavaScript that every visitor downloads. The same goes for mobile apps: the key is inside the file people install.

Check your own site in five minutes

Only test sites you own or are allowed to test. From a terminal, this prints the status code for a few well-known paths:

for p in .env .git/config .git/HEAD backup.zip phpinfo.php wp-config.php.bak; do
  echo "$p -> $(curl -s -o /dev/null -w '%{http_code}' https://yoursite.com/$p)"
done

A 404 or 403 is what you want. A 200 needs a second look, because single-page apps often answer 200 with their normal home page for any address. Open the URL in a browser and check whether you're seeing your settings or just your site.

Then look beyond that list. Search your project history for strings that look like keys, and check the places you might have forgotten: old repositories, shared documents, chat messages, and the JavaScript your site serves (open the browser's developer tools, go to the Sources tab, and search for words like key, secret and token).

If you find one: do these in order

1. Rotate first, investigate second. Create new credentials and revoke the old ones before anything else. Every minute the old key works is a minute someone can use it.
2. Rotate everything in the file, not just the one you noticed. Database password, mail login, payment keys, third-party tokens, session or encryption secrets.
3. Check for use you didn't make. Look at the provider dashboards for unusual activity: odd logins, unexpected charges, new users, large data exports, API calls from places you don't operate.
4. Close the hole. Fix the cause so the new secrets don't leak the same way (see below).
5. Tell the people who need to know. If customer data could have been reached, you may have legal or contractual duties to report it. Get advice early rather than late.
6. Clean the history if the key was in a repository. Tools like git filter-repo or BFG Repo-Cleaner can strip it out, but treat this as tidying. The key is already compromised, so rotation is what protects you.

Close the door properly

Point the server at a public folder

Your web root should contain only what visitors are meant to download. Frameworks like Laravel, Symfony and Next.js are designed around this. The project's private files sit one level above.

Block dotfiles as a safety net

Even with a correct setup, one rule that denies anything starting with a dot costs nothing. On Nginx:

location ~ /\.(?!well-known) {
    deny all;
}

And on Apache:

<FilesMatch "^\.">
    Require all denied
</FilesMatch>

Keep secrets out of version control

Add .env to .gitignore on day one. Commit a .env.example with the variable names but fake values, so teammates know what to fill in. Turn on your host's secret scanning if it has one. GitHub, for example, offers secret scanning and push protection that can block a commit containing a recognised key.

Use the right kind of key in the right place

Many services issue two types. Stripe, for instance, has publishable keys (starting pk_) that are meant to appear in a browser, and secret keys (starting sk_) that must never leave your server. Mixing them up is a classic mistake. Where a key has to be public, such as a maps key, restrict it to your domain or your app's ID so it's useless elsewhere.

Give each key the smallest job possible

A key that can only send email can't drain your database. Create one per service and per environment, with only the permissions it needs. When something leaks, the damage stays small.

What about mobile apps?

Assume that anything you put inside an app can be read. People unpack app files for fun. If your app needs to call a service with a secret key, have it call your own server instead, and let that server hold the key and decide what the app is allowed to do.

The short version

• Test /.env and /.git/config on your site today.
• If anything is exposed, rotate every secret first and ask questions after.
• Serve only a public folder, block dotfiles, and keep .env out of Git.
• Use restricted, single-purpose keys, and never ship secret keys inside an app.

Want a second pair of eyes? Exposed files and keys are one of the first things we look for in an audit, along with the other issues in our security checklist.