Free .env Leak Scanner — Check 13 Paths in One Click

Our env leak scanner online checks whether your .env file — or any of 12 common variants — is publicly accessible on your production URL. Paste your URL, click check, and see the HTTP status code for every path in seconds. No signup. No account. No install required.

This post explains what the tool checks, how to read the results, and what to do if you get a 200 back.

Check your URL now — free .env Leak Scanner →

What the .env Leak Scanner Checks

The scanner sends a HEAD request to each path and records the HTTP response code. It never reads the file contents — it only checks whether the server responds to the request. A HEAD request is enough: if the server returns 200, the file is accessible via a standard GET request too.

Here are all 13 paths the scanner checks:

Path	Why it matters
`/.env`	The main environment file. Contains everything.
`/.env.local`	Common in Next.js and React projects. Frequently holds local overrides with real credentials.
`/.env.production`	Production-specific variables. Often the most sensitive file in the project.
`/.env.backup`	Created by developers before editing. Left on servers constantly.
`/.env.development`	Development environment config. May contain staging database credentials.
`/.env.staging`	Staging-specific secrets. Often shares credentials with production.
`/.env.old`	Renamed by developers doing manual cleanup. Frequently forgotten.
`/.env.bak`	Another common backup naming pattern. Same story.
`/.env.save`	Less common but real. We've seen it in deployed projects.
`/.env.copy`	Created when developers duplicate environment files for reference.
`/.env.orig`	Another backup convention. Happens when patching or merging configs.
`/.env.test`	Test environment config. Sometimes contains real third-party API keys.
`/.git/HEAD`	Not an `.env` file, but if `/.git/` is publicly accessible, an attacker can reconstruct your entire source code — including every `.env` ever committed.

The /.git/HEAD check deserves its own mention. A 200 there doesn't mean a specific file is exposed — it means your entire git history may be reconstructable. That's a different category of problem, and it's serious.

Why This Risk Is More Common Than You Think

Most developers assume their .env file is safe. They're on Vercel, or they never uploaded the file manually, or surely someone would have told them. That's the gap.

The actual causes are less dramatic than they sound:

Web server defaults. Nginx and Apache serve files from the document root unless explicitly told not to. If your .env is there — because it was committed to git and deployed, because a build step created it, or because you copied it manually — the server will serve it as plain text. No extra configuration required. No warning. It just works, quietly.

Backup files from manual edits. Someone SSHes into a server to make a quick change. Before editing .env, they run cp .env .env.backup. They make the change, restart the service, and move on. The backup file stays on the server indefinitely. These files don't get into .gitignore because they were never in git. They just live on the filesystem until someone looks.

AI-scaffolded projects. Vibe coding security risks include this pattern consistently. AI tools scaffold projects fast, but they don't always configure server blocks correctly for self-hosted deployments. The Nginx config gets generated, the project gets deployed, and the dotfile deny rule never makes it in. Veracode's State of Software Security report found that 45% of AI-generated code has at least one vulnerability. Misconfigured static file serving is a recurring category.

The .env.backup problem specifically. We scanned deployed URLs across projects that had no /.env exposure and still found /.env.backup returning 200. The main file was properly excluded. The backup wasn't. That's why checking 13 paths matters — checking one isn't enough.

This falls squarely under OWASP A02:2021 Cryptographic Failures — storing secrets in a way that makes them accessible to unauthorized parties. Per the Twelve-Factor App methodology, config belongs in the environment, not in files deployed to a server. The .env pattern is a development convenience that breaks down when the file makes it onto a public-facing server.

What Each Result Means

The scanner returns one of three status codes for each path. Here's how to read them:

200 OK — Exposed

The file is being served. Anyone who knows the URL can download it right now. This is the status that requires immediate action.

A 200 on /.env.backup is the same severity as a 200 on /.env. The contents may be slightly different, but both give an attacker your secrets.

403 Forbidden — Partially Mitigated, Not Safe

The server knows the file exists but is currently denying access. This is not a clean bill of health.

A 403 means the file is on the server's filesystem. A configuration change, a server restart with a slightly different config, or a different request pattern could expose it. The right fix is to remove the file from the server, not just block it. A 403 means you haven't been bitten yet. It doesn't mean you're safe.

404 Not Found — Safe for This Path

The server isn't serving that file at this path. For the web server exposure vector, you're clear.

Note the scope: the tool checks HTTP accessibility only. A 404 on all 13 paths means your server isn't serving these files. It doesn't tell you whether the file is in your git history, whether it was in a previous commit that's still accessible, or whether secrets were hardcoded elsewhere in your codebase. For that broader check, scan your full repo with Data Hogo.

Which Platforms Protect You Automatically

Not all deployment platforms behave the same way.

Platform	`.env` Protected?	Notes
Vercel	Yes	Vercel's runtime excludes dotfiles from serving. If you get a `200` on a Vercel URL, the file is exposed through git — not the file server.
Railway	Yes	Variables are injected at runtime from the Railway dashboard. Deployed `.env` files aren't served.
Render	Yes	Same as Railway — environment variables are injected, not deployed as files.
Nginx (self-hosted)	No — config required	Nginx serves everything in the document root by default. You need an explicit `location ~ /\.env { deny all; return 404; }` block.
Apache (self-hosted)	No — config required	Apache requires a `FilesMatch` directive to block dotfile access. Not configured by default.
Docker + Nginx	Depends	If `.env` is `COPY`'d into the image and Nginx serves from that directory, it's exposed. Use `.dockerignore` to exclude `.env` from the build.

If you're on Vercel, Railway, or Render, the file server risk is largely handled. The risk that remains is git exposure — a committed .env in your repo that an attacker with repo access could read directly. For that, see how to fix an exposed .env in git history.

If you're self-hosted, the scanner results are your first real look at whether your server config is actually blocking these paths.

What to Do If the Scanner Finds an Exposure

If any path returns 200, treat it as an active incident. Not a future risk. An active one.

First: stop the bleeding. Block or remove the exposed file from your server. For Nginx, the one-liner is location ~ /\.env { deny all; return 404; } added to your server block, followed by a reload. For Apache, a FilesMatch directive in your config. For Docker, check whether the file was COPY'd into the image.

Second: rotate every secret in the file. Not just the ones you think matter. A leaked SMTP password enables phishing from your domain. A leaked JWT secret compromises every active user session. When the whole file is out, you rotate everything. For the full rotation checklist with provider-specific revocation URLs, see our guide on fixing an exposed .env in production.

Third: verify the fix. Run the scanner again after making changes. Confirm every path returns 404. A 403 isn't done — the file is still on the server.

Scope note: This tool checks whether your secrets are exposed via HTTP right now. It doesn't scan git history, check for hardcoded credentials in your codebase, or analyze your Supabase RLS policies. For a full security picture, the free security score tool runs broader checks across your deployed URL.

Frequently Asked Questions

How do I check if my .env file is publicly accessible?

Paste your URL into Data Hogo's free .env Leak Scanner. It checks 13 common paths and returns the HTTP status code for each. A 200 on any path means that file is being served publicly.

What paths do attackers check for .env files?

Not just /.env — also .env.local, .env.production, .env.backup, .env.old, .env.bak, .env.staging, and more. Automated scanners probe all of these. Data Hogo's tool checks all 13 in one pass.

Does Vercel protect my .env file automatically?

Yes. Vercel, Railway, and Render all exclude .env files from being served. If you're on one of these platforms and the scanner returns 404 across the board, the web server risk is handled. Self-hosted deployments on Nginx or Apache require explicit deny rules in your server configuration.

What happens if my .env file is exposed?

Every secret in the file is accessible to anyone who requests it. Database passwords, Stripe keys, JWT secrets, email credentials — each enables a different class of attack. Treat any .env exposure as an active incident: block the file, rotate every secret, verify the fix. For the complete response process, see how to fix an exposed .env in production.

The scanner is free, takes about 10 seconds, and requires no account.

Check 13 common .env paths on your URL now →

If you want to go further — check your HTTP security headers, test your overall security score, or scan your full codebase for hardcoded secrets — those tools are free too: