Lesson 1 of 1 in The Edge And Its Secrets
Where The Edge Is
Your box has an edge — the reverse proxy the world talks to — and just inside it, your secrets. Two common mistakes cross that line the wrong way: a proxy that hands out the real address behind it, and a `.env` sitting in the folder every scanner reads first.
3 min read
Not yet reviewed
I put Nginx in front of the app and a CDN in front of that. The real server's address is hidden now, right?
Usually — until it isn't. If your proxy ever fetches a URL I give it, or answers on its raw address, it tells me exactly where the real box lives, and then the CDN in front is a curtain in front of an open door.
The proxy that gives itself away
A reverse proxy terminates TLS and forwards requests to your app, and a CDN in front hides the origin's address so attacks hit the CDN, not the box. The value is entirely in the origin staying secret — and it leaks in ordinary ways: the origin still answering on its bare IP, an error page echoing an internal hostname, a feature that makes the *server* fetch a URL and so reveals the address it fetches from. Real forum software has shipped exactly this, leaking the backend IP behind the CDN.
Leaks the origin
Origin answers on its public IP directly.
A server-side "fetch this image" feature.
Errors that print internal hostnames.Keeps the edge
Origin firewalled to accept only the CDN.
No server-side fetch of user URLs (or allowlisted).
Generic error pages; details in the log.The fix for a leaking origin is a firewall rule — accept traffic only from the CDN's addresses — which is the default-deny chapter again, applied to who may reach you rather than which port.
The file every scanner reads first
Just inside the edge is where secrets live: database passwords, API keys, the app's own session secret. The single most common way they leak is the .env file left in the web root, where the server will happily serve it as a plain text file to anyone who asks — and /.env is one of the most-requested paths on the entire internet, tried against every site, constantly.
# keep secrets OUT of the web root entirely, and lock the file down
/srv/app/.env chmod 600 # only the app's user can read it
# and belt-and-braces: tell the web server to refuse dotfiles
location ~ /\. { deny all; }
- Line 2
600means read/write for the owner and nothing for anyone else. A secret readable by every user on the box is a secret one compromised process away from stolen. - Line 4Even outside the web root, denying access to dotfiles at the server is cheap insurance against the day a path is misconfigured.
Your .env is outside the web root and chmod 600. Someone says the deny all rule for dotfiles is now redundant. Keep it or drop it?
.env.backup somewhere served. Security in layers means each control assumes the others might fail — the file permission, the location outside the web root, and the server rule each cover a different way the secret could be exposed, and the cheap redundant one is exactly the kind you keep.Lock down this web-server config so dotfiles like .env are never served. Append a rule so the file contains deny all.