TL;DR
Our .env file containing database credentials, Stripe keys, and third-party API tokens got indexed by Google after a misconfigured server made it publicly accessible. We discovered it when a friend Googled our company and found our secrets in search results. Emergency response included rotating all credentials, fixing server config, and requesting removal from Google's index.
There's a special kind of horror when you realize your application secrets are sitting in Google search results. Anyone could find them. Anyone could've already used them. This is the story of how our .env file became public knowledge.
The Accidental Discovery
A friend was doing some research on our startup for a potential partnership. He texted me something that made my blood run cold.
"Hey, is this supposed to be public? I Googled your company and found a page with what looks like database passwords and API keys."
I grabbed my laptop and searched our company name along with ".env" and there it was. Our entire .env file, beautifully formatted by Google's cache, complete with PostgreSQL database credentials, Stripe live API keys, SendGrid tokens, AWS access keys, and JWT secrets.
How Did This Happen?
The investigation revealed a perfect storm of mistakes. Our server was running a simple static file server for a marketing landing page. When we migrated our main app to the same server, someone accidentally placed the .env file in the web root directory.
Our nginx configuration was set to serve any file requested, and we didn't have a robots.txt blocking sensitive directories. Googlebot came along, indexed everything it could find, and that included our .env file.
The Perfect Storm
- .env file in web-accessible directory
- No robots.txt file to block indexing
- Server configured to serve all files
- No nginx rules blocking sensitive files
- No monitoring for exposed credentials
The Emergency Response Timeline
Friend alerts us to indexed .env file in Google search results.
Moved .env file out of web root. Added nginx rules to block access to all dotfiles.
Started rotating all exposed credentials, beginning with database and Stripe.
Submitted URL removal request through Google Search Console.
All credentials rotated. Checked logs for suspicious access.
What We Changed Immediately
# nginx - Block all dotfiles
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
# Block common sensitive files
location ~* (\.env|\.git|\.htaccess)$ {
deny all;
}
We stopped using .env files in production entirely. Instead, we moved to proper secrets management using environment variables set at the system level.
- Never store .env files in web-accessible directories
- Configure your server to block sensitive files by default
- Use proper robots.txt to prevent indexing of sensitive paths
- Monitor for exposed credentials with tools like GitGuardian
- Use proper secrets management in production, not .env files
How do I check if my .env file is publicly accessible?
Try accessing it directly via your domain (e.g., yourdomain.com/.env). Also search Google for "site:yourdomain.com filetype:env" to see if it's been indexed.
How long does it take for Google to remove indexed pages?
Using Google Search Console's URL removal tool, temporary removal typically happens within hours. Permanent removal requires ensuring the page returns a 404 and can take days to weeks.
Should I use .env files in production?
It's generally better to use system environment variables or a proper secrets manager (like AWS Secrets Manager or HashiCorp Vault) in production.
Don't Let This Happen to You
Scan your vibe coded projects for exposed secrets and misconfigured servers.
Check Your Vibe Now