.env Wide Open

The first thing I did after deploying Planq. Opened a browser and typed my product’s URL with /.env at the end.

The file came right through. Database password. Encryption key. SMTP credentials. All in plain text. On a service I’d invited people from LinkedIn to use a week earlier.

The Reason Was Simple

The frontend serves any URL if it doesn’t match a route. Nginx wasn’t blocking hidden files. A classic. But this post isn’t about the bug.

This post is about the fact that I knew. I knew .env shouldn’t be exposed. I knew Docker opens ports to the whole world by default and that the backend was accessible bypassing nginx. I knew the server was revealing its version in every response. Three things from any security checklist. And all three were wide open.

Features Are Visible, Holes Aren’t

When you’re a solo founder, security competes for attention with features, bugs, deployment, and content. And it loses. Because features are visible, and holes aren’t. Until someone walks in.

Fixed in an evening. Hidden files blocked. Ports listening on localhost only. Server version hidden. Three lines in a config. Three lines separating “I’m in the cloud” from “my data is in the cloud.”

The Foundation Was Solid

TLS 1.3, HSTS, CSRF tokens, JWT in httpOnly cookies, rate limiting, Swagger hidden. Not everything was bad. But three obvious holes cancel out any foundation.

Priorities, Not Knowledge

Security doesn’t break. It gets postponed. “I’ll do it after the release.” “It’s just an MVP.” “Not critical yet.” And then the MVP becomes a product. And “later” never comes.

The most useful thing I took away is a habit. Write, deploy, switch gears. Now try to break what you just shipped to production. It’s uncomfortable. You find things you knew about but didn’t do. But at least you find them, not someone else.

If you’ve launched a product and put off security for later, go open /.env right now. Seriously.