TL;DR
A social media scheduling startup's .env file containing database credentials, Stripe keys, and third-party API tokens got indexed by Google after a misconfigured server made it publicly accessible. The team discovered it when a prospective investor Googled the company and found the 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 one social media scheduling tool's .env file became public knowledge.
The Accidental Discovery
A prospective investor was doing due diligence on the startup before a seed round meeting. He texted the founder something that made their 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."
The founder grabbed a laptop and searched the company name along with ".env" and there it was. The 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. The server was running a simple static file server for a marketing landing page. When the team migrated the main app to the same server, someone accidentally placed the .env file in the web root directory.
The nginx configuration was set to serve any file requested, and there was no robots.txt blocking sensitive directories. Googlebot came along, indexed everything it could find, and that included the .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
Prospective investor alerts the team 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 the Team 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;
}
The team stopped using .env files in production entirely. Instead, they 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.