Pro Logica

    Exposed .env File

    If https://your-domain/.env downloads a file full of KEY=value lines, every secret in that file is compromised. Treat it as stolen, not "at risk." Automated bots constantly request /.env on websites because it's one of the easiest ways to get database passwords, API keys and payment credentials. Fixing it takes two steps, in this order: rotate everything in the file, then stop serving it.

    The Pro Logica AI App Security Check tests for a public /.env (and /.git) on apps you own. Run the free check.

    How to confirm it

    Open a private browser window and go to https://your-domain/.env. Then run:

    curl -s -o /dev/null -w "%{http_code}\n" https://your-domain/.env
    
    • 404 or 403: not exposed at that path.
    • 200 that shows your app's homepage HTML: that's a single-page app fallback, not the file. You're fine at that path.
    • 200 that shows lines like DATABASE_URL=…: exposed. Start rotating now.

    Our scanner makes one request to /.env and flags it only when the response is a 200 that looks like KEY=value lines. That's how it avoids false alarms from single-page app fallbacks. We record the path and status code only. We never store or show the contents. This probe runs only when you confirm you own the app or have permission to scan it.

    Check the common variants by hand too: /.env.local, /.env.production and /.env.backup.

    Step 1: Rotate every secret in the file

    Go line by line. For each credential:

    1. Create a new value at the provider. That could be a new database password, a new Stripe secret key, a new OpenAI key, new AWS access keys or a new SMTP password.
    2. Update the new value in your host's secret store (Vercel, Netlify, Replit Secrets, Lovable Secrets, Supabase function secrets) and redeploy.
    3. Revoke or delete the old value. Don't just leave it unused.
    4. Check the logs. Look at Stripe events, AWS CloudTrail, your database's connection logs and your email provider's sending history for activity you don't recognize since the file was public.

    Don't skip low-value-looking entries. A JWT signing secret lets an attacker make valid login tokens. A Supabase service_role key bypasses all Row Level Security. A webhook secret lets them fake events.

    Step 2: Stop serving it

    How a .env ends up public, and how to fix each case:

    • It's in public/ or static/. Vite, Next.js and most frameworks copy everything in public/ to the site as-is. Move .env to the project root (outside public/) and redeploy.
    • The server serves the project root. Code like express.static("."), express.static(__dirname), or a Python static handler pointed at the repo publishes every file, including .env and .git. Serve only your build folder (for example dist/).
    • A manual upload of the whole folder to shared hosting or a bucket. Upload only build output. On Nginx, also block dotfiles with location ~ /\. { deny all; }, and keep the /.well-known/ path open if you use it.
    • It's committed to Git. Add .env* to .gitignore. Removing it from the latest commit isn't enough, because it's still in history. Rotate first, then follow GitHub's guide to removing sensitive data if the repo is shared or public.

    Then confirm: the curl check returns 404 or 403, and a rescan no longer shows the finding.

    Keep secrets out of env files the browser can see

    A .env that's never served can still leak through your bundle. In Vite, anything named VITE_… is copied into your JavaScript. In Next.js, the same goes for anything named NEXT_PUBLIC_…. Secret keys must never use those prefixes. See Exposed API key in frontend.

    The same problem: a public /.git folder

    If /.git/HEAD or /.git/config loads, your repository metadata is public. Free, widely available tools can rebuild your source code from it, including every secret ever committed. When you confirm ownership, we check both paths once each. The fix is the same as for .env: rotate anything that was ever committed, and stop serving the repo directory.

    Why this matters for your business

    An exposed .env is how a quick weekend app turns into a surprise cloud bill, a spam campaign sent from your email account, or a database someone else downloaded. In the scan it's critical-severity and one of the heaviest deductions. For context, in our passive check of 18 public showcase apps, we deliberately did not request /.env on third-party sites. That probe runs only with owner permission. We validated it on a local test fixture with a planted .env, where it was detected.

    Related

    FAQ

    Is deleting the .env file from my server enough?

    No. Anyone may have copied it while it was public, and bots check for it constantly. Rotate every secret in it, then remove it.

    My site returns 200 for /.env but shows my homepage. Is that bad?

    Usually not. Single-page apps often return index.html for any path. Check the content. If you don't see KEY=value lines, the file isn't exposed at that path. Our scanner makes the same distinction.

    Does a .env in my GitHub repo count as exposed?

    If the repo is public, or was at any point, yes. Rotate, add .env* to .gitignore, and clean the history.

    Will your scan download my secrets?

    We make one request to /.env and record only whether it looked like an env file, plus the status code. The contents are never stored or displayed, and this check only runs with your permission.

    Check whether /.env or /.git is public on your app. Run the free AI app security check. Need help fast? Call 949-205-7333.

    By Pro Logica