Publicly accessible .env: the 10-second test

The one-line test

Replace yoursite.com with your own domain and run:

curl -s https://yoursite.com/.env

If the response contains lines like DATABASE_URL=... or STRIPE_SECRET_KEY=... instead of a 404 page, that's a critical vulnerability — all your server secrets are accessible to anyone who knows the URL, no authentication required. Vetora automatically tests three common variants: /.env, /.env.local and /.env.production.

Why it happens with a fast deployment

On a plain Node/Express server, if the project directory is used directly as the public root (for example with express.static('.') instead of express.static('public')), every file at the root — including .env — becomes reachable by its path. A scaffold generated quickly to "just serve the app" easily skips this distinction between public files and project files.

On Next.js, Vite or most modern frameworks this is rarer by default (the server only serves the build output), but the risk comes back as soon as a custom static export, a misconfigured proxy, or a generic file server ends up pointing at the wrong folder.

The .git folder leaks the same thing, a different way

Same vulnerability, different door: if /.git/config responds, the project's entire Git history is potentially recoverable — including old commits that once contained a secret since removed from the current code, but still present in history:

curl -s https://yoursite.com/.git/config
# if it responds with [core] / repositoryformatversion, the .git folder is exposed

Tools like git-dumper automate reconstructing the full repository from there. A secret "committed by mistake then removed in the next commit" isn't really removed as long as .git is exposed.

The fix

The good news: it's almost always a server configuration issue, not an architecture problem to rebuild.

• Nginx / Caddy — explicitly block hidden files/folders:

# nginx
location ~ /\.(env|git) {
    deny all;
    return 404;
}

• Vercel / Netlify — environment variables set in the dashboard are never served as static files; the risk mostly comes from a .env committed by mistake to the deployed Git repo, or a public folder that includes the project root.
• Either way — add .env* to your .gitignore right when the project is initialized, before the first commit — not after noticing the problem.

If a .env has already been exposed, fixing the server config isn't enough: rotate every secret it contained. It may have been indexed, cached, or scraped before you noticed.

This test takes no longer than an automated scan — run a Vetora scan to check this and about a dozen other common vulnerabilities in one pass.