criticalSeverity: criticalRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Deploy config + secret rotationWhere it livesImplementationThis fix is applied in: Deploy config + secret rotation. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+40 posture+40 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed .env: rotate the secrets, then get the file off the web

Rotating every credential in a public .env and removing it from the web root closes a direct line to your database and APIs

The threat

The scanner requested /.env and got back KEY=value lines. A .env file is where an app keeps its secrets: DATABASE_URL, API keys, SMTP passwords, JWT signing secrets, third-party tokens. It is meant to sit next to your code and be read by the app at startup, never handed to a browser. Reachable over http, every one of those values is one click from the entire internet.

This is not a hypothetical someday risk. Automated bots request /.env across millions of hosts a day precisely because it pays off so often, so the safe assumption is that it has already been read. The good news is that this is fully recoverable, and the fix is mechanical.

The exact fix

Step 1, contain: rotate every secret in the file first. Go key by key and change each value at its source:

  • Database passwords: change them, then update the app config.
  • API keys and tokens (Stripe, SendGrid, AWS, and so on): revoke and reissue in each provider’s console.
  • JWT and session signing secrets: generate new ones. This logs everyone out, which is exactly the point.
  • SMTP and webhook credentials: reset them.

Do this before anything else. Until the secrets are rotated, removing the file only closes the door on a room that has already been photographed.

Step 2, stop serving it. A .env should never sit in the web root or the build output.

  • Keep it out of deploys: add .env to .gitignore, and to .netlifyignore on platforms that publish a folder. Never copy dotfiles into the published directory.
  • Serve secrets from the environment, not a file. On Netlify, Vercel, and most managed hosts, set them as environment variables in the dashboard. The app reads them from the environment, and there is no file left to leak.
  • Block the path at the server as a backstop.

nginx:

location ~ /\.env {
    deny all;
    return 404;
}

Apache:

<FilesMatch "^\.env">
    Require all denied
</FilesMatch>

Check git too. A .env should never be committed. If one is in your history, those secrets are compromised regardless of the web server, and the exposed .git page covers cleaning that up.

Verify it

curl -sI https://yourdomain.com/.env

You want HTTP/2 404 (or 403). Any 200 means the file is still reachable, and you are not done until it returns a 404 and the secrets are rotated.

Proof

The ApeCyber scanner confirms this with a single unauthenticated GET of /.env from the outside, reading nothing else. apecyber.com keeps its secrets in Netlify’s environment settings, so there is no .env anywhere in the served output to request. At −40 this is the heaviest single hit on a posture score, and rotating plus removing the file clears it completely.