Env file exposed: how to check your site for .env, .git, source maps and backups

What an exposed env file is, and how it ends up public

A .env file holds your app's configuration as KEY=value lines: the database URL with its password, the Stripe secret key, the OpenAI key, the secret that signs session tokens. Your server reads it when it starts. A browser should never be able to download it. The file is exposed when the web server treats it like any other static file, so a request for https://your-app.com/.env returns its contents instead of a 404.

Nobody publishes a .env on purpose. It ends up public in one of three ways:

• The web root is the whole project. A server whose root points at the folder you cloned from Git serves everything in it: .env, .git/, package.json, the SQLite file from development. This is the classic setup on a VPS running nginx or Apache.
• The file sits in a folder your framework publishes as is. Next.js serves every file in public/ from the root of your site, and Vite copies its public/ folder to the root of dist without touching it. A .env or a database export dropped there ships with the next deploy.
• The host publishes more than you think. On Vercel, a project with no build step and the Other framework preset is served from its public folder, or from the project root when there is none. The Vercel CLI uploads your folder minus a default ignore list that includes .git, .env.local and .env.*.local, but not .env or .env.production. Vercel's documentation recommends a .vercelignore file to keep private files from being deployed and served.

What a stranger can do with each exposed file

The .env file is the famous one, but it belongs to a family. Any file that should stay on your laptop or inside your server becomes a leak once a browser can fetch it by name.

What an exposed .git folder gives away

The .git folder at the root of a project is the repository itself. In the words of Sysdig's researchers, it contains the complete commit history, the configuration files, the branches and the references. If your server serves that folder, anyone can download its contents and rebuild your source code. Turning off directory listing does not stop it: the layout of a Git repository uses standard names such as HEAD, config and refs/heads/main, which can be requested one by one.

Three things make it worse than a copy of today's code:

• History keeps deleted secrets. A key committed once and removed the next day is still stored in the repository's objects. If the folder was public, treat every secret that was ever committed as leaked, not only the ones in the current files.
• The config can hold a token. When a repository is cloned over HTTPS with a token in the URL, .git/config keeps that URL. Sysdig notes that an exposed folder can include passwords or API keys when the repository requires them.
• It maps what your interface hides. Commit messages, branch names and file paths point to admin pages and internal APIs that no button in your app links to.

Attackers already collect these at scale. In 2024, Sysdig described EMERALDWHALE, an operation that scanned the internet for exposed Git configuration files between August and September of that year. It stole more than 15,000 cloud service credentials, collected credentials for over 10,000 private repositories, then cloned repositories with the stolen tokens and pulled more keys out of their code.

Source maps: your original code, served next to the bundle

Your build tool turns your source into minified JavaScript. A source map is a JSON file, usually ending in .js.map, that maps the minified code back to the original so a debugger can show readable lines. The format is standardized as ECMA-426: its sources field lists your original file paths, and its optional sourcesContent field carries the original source text itself. A comment at the end of the bundle, such as //# sourceMappingURL=app.js.map, tells the browser where to find it.

Anything in a browser bundle is public already, map or not. A source map makes it readable and puts back what minification removed: your folder structure, your comments, the admin pages your interface hides behind a role check, every endpoint the app calls, and any key someone pasted into the code. That key was in the bundle all along; the map just makes it easy to find. The guide to API keys exposed in the frontend sorts the keys that may live there from the ones that never should.

Backups, dumps and database files left in the web root

The third family is files that were never meant to be deployed at all: a backup.zip made before a risky change, a dump.sql exported to move a database, a SQLite file used during development, an editor leftover such as .env.bak or config.php~. On a server whose web root is the project folder, anyone who guesses the name can download them. The web server does not know that a .sql file holds your users: it serves it like an image. A coding agent that exports a database before a migration, or creates a SQLite file for a quick local setup, does nothing wrong on your laptop. The problem starts when that file lands in the folder you deploy, so check the file list of what you ship, not only your source code.

How to check your own site for exposed files

Run these checks against your own domain only. They read, and they change nothing. The loop requests the usual paths and prints the status, the content type and the size of each answer. The last path is a file that does not exist: it is your baseline, the answer your site gives for a missing file.

SITE="https://your-app.example"
for p in /.env /.env.local /.env.production /.env.bak /.git/config \
         /backup.zip /backup.sql /dump.sql /db.sqlite /data.db \
         /this-file-does-not-exist.txt; do
  curl -s -o /dev/null -w "%{http_code}  %{content_type}  %{size_download} bytes  $p\n" "$SITE$p"
done

1. 1

   A 404 or a 403 is what you want

   The file is not served. Nothing more to do for that path.

2. 2

   A 200 with text/html and the baseline's size is not the file

   Single page apps answer every unknown path with index.html and a 200. If the type and size match the baseline line, you are looking at your home page, not at a leak.

3. 3

   Anything else: look at the first bytes

   Run curl -s "$SITE/.env" | head -c 300 for each path that stands out. KEY=value lines mean the env file is served. [core] means the Git config is. A file that starts with SQLite format 3 is a database, CREATE TABLE or INSERT INTO is a dump, and PK is a zip archive.

4. 4

   Look for source maps

   Copy the URL of one of your JavaScript files from the page source, add .map to it and request it with curl. A JSON answer with "version":3 and a sources list is a source map. Before you deploy, find dist build .next/static -name "*.map" 2>/dev/null lists the maps in your build output.

5. 5

   Check what you deploy, not only what you serve

   List the files in your build output (dist, out or build) and in your public folder, and search your repository for committed env files with git ls-files | grep -i env. If .env shows up, git rm --cached .env stops tracking it (add it to .gitignore too), but it stays in the history, so rotate its values. A file that is not in the deployed folder cannot be served from it.

Found one? Rotate first, then block

Blocking the path stops the next download. It does nothing about copies already taken, and the Unit 42 case shows that collecting env files happens at the scale of 110,000 domains. Work in this order:

1. Rotate every secret in the file. Database password, API keys, webhook secrets, the session or JWT secret (rotating it signs everyone out, which is the point), mail credentials. A key you did not rotate still works for whoever copied it. Give each new key only the permissions the app needs.
2. Look for use. Check your server's access logs for successful requests to the path, and each provider's dashboard for usage you do not recognize. What to do when an API key leaks has the steps for the providers that leak most.
3. Remove the file from the deployed folder and redeploy. Then block the path at the server, as shown below, so the next mistake is caught.
4. If `.git` was public, widen the search. Rotate the secrets that appear anywhere in the history, not only in the current files.
5. If the file held a Supabase service role key, follow the service role key guide: that key skips every row level security policy.

How to block these files on nginx, Apache, Vercel and Netlify

The first fix is the same on every host: publish the build output, never the project folder. The rules below are a second layer, for the day someone drops a file in the wrong place.

nginx

Point root at the build output, for example /var/www/app/dist, never at the cloned repository. Then refuse dotfiles and the usual backup extensions:

# Every dotfile and dot folder, except /.well-known/ (used for certificates)
location ~ /\.(?!well-known/) {
    return 404;
}

# Dumps, databases, backups, archives and source maps
location ~* \.(sql|sqlite|db|bak|old|swp|zip|map)$ {
    return 404;
}

Two nginx rules decide whether this works. Regular expression locations are checked in the order they appear in the configuration, and the first match wins, so put these blocks above your other regex locations, such as a \.php$ handler. And when the longest matching prefix location has the ^~ modifier, nginx does not check regex locations at all: files under a location ^~ /static/ block are not covered by the rules above.

Apache

On Apache, point DocumentRoot at the build output as well. Then add these rules to the site's configuration, or to a .htaccess file at the web root if the server allows overrides:

# Every dotfile and dot folder, except /.well-known/
RedirectMatch 404 /\.(?!well-known/)

# Dumps, databases, backups, archives and source maps
<FilesMatch "\.(sql|sqlite|db|bak|old|swp|zip|map)$">
    Require all denied
</FilesMatch>

Vercel

With Next.js, files are served from public/ and from the build output, so the rule is simple: env files stay at the project root, and nothing secret goes in public/. Keep production values in the project's environment variables on Vercel rather than in a committed file. The risky case is a site with no build step: with the Other preset and no public folder, Vercel serves the project root. The CLI's default exclusions skip .env.local but not .env, so add a .vercelignore:

.env
.env.*
*.sql
*.sqlite
*.db
*.zip
*.map

Netlify

Set the publish directory to your build output (publish = "dist" in netlify.toml, or whatever folder your framework writes) so the project root is never published. As a safety net, a _redirects rule can answer 404 for a path. By default a rule does not apply when a real file exists at that path, so add ! to force it:

/.env              /404.html  404!
/.env.local        /404.html  404!
/.env.production   /404.html  404!
/.git/*            /404.html  404!

The traps after the obvious fix

• Variants of the name. Blocking /.env alone leaves .env.production, .env.bak, .env.old and .env.save. Block the pattern, as the nginx rule above does, not one file.
• A cache keeps the old copy. If a CDN sits in front of your server, purge it after removing the file, or it may keep serving the copy it stored.
• The env file was never served, but its values are in the bundle. Variables starting with NEXT_PUBLIC_ or VITE_ are copied into the JavaScript at build time, so a secret in one of them is public without any .env request. The Next.js security guide covers public variables and server-only code.
• Debug routes that print the environment. A route such as /api/env or /api/debug, written to troubleshoot a deploy, returns the same secrets as a .env file through your own code. Search your routes for anything that returns process.env.
• Deleting the file from Git does not delete it from history. If .env was ever committed to a repository other people can read, rotate its values.

What Keybrum requests on a live app

Keybrum runs these checks as part of its attack library, on apps whose owner proved ownership. Each one only reads:

• web.env-file requests /.env, /.env.local and /.env.production, and compares each answer with the answer for a file that does not exist, so a single page app's fallback never counts as a leak. The report lists the variable names it found, with the values masked.
• web.git-folder requests /.git/config and reports the folder as served only when a real Git configuration comes back.
• web.exposed-files requests SQL dumps, SQLite files, a backup archive, server source files, .npmrc, docker-compose.yml, service account keys and .DS_Store. It reads only the first bytes of each file, confirms the type by its content, and does not store the content.
• web.source-maps checks whether source maps are served next to your JavaScript.
• Other attacks look for .bak and ~ copies of config files, directory listings on upload and backup folders, and debug routes that return environment data.

Every env or data file found also goes through the secret detectors used on your JavaScript, so a Stripe or OpenAI key inside it is reported on its own. The fix goes to your coding agent through MCP, and Keybrum attacks again after the fix, and on every deploy with a plan. For the wider list of what to review before launch, see the vibe coding security checklist.