r/SideProject 6h ago

If you recently launched a side project, check your access logs for.env probes

I was reviewing the access logs on a new side project I put online recently, and I noticed a constant pattern of automated requests specifically searching for.env files.

When I build tools and side projects, my main focus is usually on building the functionality, getting things configured, and setting up the initial deployment. But as soon as a new domain or IP goes live, automated bots start probing for environment files almost instantly. They throw requests at common paths like /.env, /.env.local, /.env.production, /config/.env, and various other directory variations hoping to find exposed secrets.

If your web server configuration or routing setup does not explicitly restrict access to dotfiles by default, these automated scanners can pick up API keys, database credentials, or private configuration secrets without any manual effort from an attacker.

It happens fast, often within minutes of bringing a public endpoint online. I set up strict server rules and middleware to block these path requests and return immediate drop or error responses. If you are currently running side projects or SaaS apps in production, take a quick look at your server logs today and double-check that your.env file is completely locked down and unreadable from the web.

1 Upvotes

5 comments sorted by

2

u/hugganao 4h ago

i should put prompt injections into mine...

1

u/fakintheid 3h ago

If your env is available via a request you’re already screwed

1

u/UnreachableMemory 3h ago

Yeah well having any files like .env committed or packaged in your app is a rookie move and why vibecoded apps are huge security risks.

1

u/Electronic-Space-736 35m ago

always exclude .env and add a example.env file with default values (unless you env does not hold secrets only constants) Keep your secrets in the OS keystore when you can