← Back to the Dotenv Exposure Checker
Typing yoursite.com/.env into a browser tab is a real, fast way to spot the single
obvious case: a plainly readable file full of KEY=VALUE lines. It is also the method
most developers already reach for first, and it genuinely works for that case.
| Check | Typing the URL by hand | This tool |
|---|---|---|
| Obvious plainly-readable .env file | Catches it | Catches it |
| A server that returns 200 with a generic page for any path (soft-404) | Can look plausible enough to misread either way | Verified against the real KEY=VALUE line shape before calling anything exposed |
| Checking all five common dotenv filenames, not just one | Manual, easy to stop after trying the bare .env | Checks .env, .env.local, .env.production, .env.production.local, and .env.development.local every run |
| Telling a live credential apart from an innocuous setting | Easy to skim past in a wall of variable names | Flags a variable NAME that matches a common secret pattern (SECRET, TOKEN, PASSWORD, API_KEY) at a higher severity |
| Repeatable in CI on every deploy | Manual, point-in-time | CLI returns a real exit code |
If you only need a one-off sanity check on a URL you're already typing into the address bar, looking is fine — it's free and you're already there. The gap this tool closes is coverage and confidence: all five relevant filenames, not just the one you thought to try, each verified against the real file shape rather than eyeballed, every time a deploy happens, with an exit code a CI pipeline can act on.
Typing yoursite.com/.env into a browser tab is a fast, real check for the single obvious case: a plainly readable file full of KEY=VALUE lines. If that's what comes back, you don't need a tool to tell you it's exposed -- though you may not notice which of the lines is actually a live credential versus an innocuous setting.
Three ways this scripted check catches and a quick manual look easily misses: (1) a server that returns its normal 200 page (a single-page app's fallback route, a themed 404) for literally any path -- glancing at a response that looks like plausible text can be misread either way without checking its actual line shape. (2) Checking only the bare .env and not the four other common filenames (.env.local, .env.production, .env.production.local, .env.development.local) that frameworks like Next.js define and that often carry the developer's own real secrets rather than committed defaults. (3) A page full of variable names is easy to skim past without noticing which ones look like a real credential -- this tool names them explicitly by pattern (SECRET, TOKEN, PASSWORD, API_KEY, and similar) as a separate, higher severity.
A manual check is a point-in-time look. A new deploy script, a server migration, or a CDN configuration change can reintroduce this exposure at any point after the last time someone happened to check. The CLI here returns a real exit code, so it can gate a deploy the same way a linter or test suite does -- catching a regression the day it ships rather than the next time someone thinks to check by hand.