Watch Your Secrets: The Attack That Hit Your Server

How to Avoid Secret Leaks When Publishing a Project to Production

On May 2, 2025, at 02:41:37 AM, an IP address from Amsterdam (213.232.87.232) began systematically scanning your server. It wasn’t looking for web pages. It didn’t want to see content. It was looking for secrets. Were you ready?

This type of attack is more common than you think. And no, it’s not Hollywood-style “hacking.” It’s just a machine making requests. But the requests are smart. And dangerous.

🔍 What was it looking for?

The list is chilling:

/.vscode/sftp.json
/server.key
/.ssh/id_rsa
/backup.sql
/.env
/cloud-config.yml
/secrets.json
/docker-compose.yml
/config.php
/.aws/credentials
/.git/HEAD
and many more...

All of them are files that have been mistakenly exposed to production in hundreds of projects around the world. And all of them may contain private keys, API secrets, credentials, sensitive configs, backups... everything.

📉 A single leak = disaster

When you publish a project—especially if you’re using frameworks like Laravel, Node.js, Django, etc.—it’s easy to forget about files like .env, config.yml, or entire directories like .git/. On StackOverflow and Hacker News, there are plenty of stories from developers who made this mistake, like the famous case where someone accidentally committed AWS keys to a public repository and within less than an hour, received bills for thousands of dollars due to malicious use of services like EC2 and S3.

🔐 Best Practices to Protect Secrets

According to secret detection platforms like ScatteredSecrets and reports on malicious traffic, these are some practices that should be mandatory:

Never publish your .env or sensitive config files. Use .gitignore.
Properly configure your server. Any file starting with a dot (.) should be denied by the HTTP server.
Avoid exposing directories like .git, .svn, node_modules, vendor, or storage.
Audit your repository. Tools like git-secrets or [truffleHog] can help detect secrets before pushing code.
Deploy only the production artifact. Never the entire source. Use pipelines to clean and package.
Monitor your logs. Requests like the ones shown above are a clear alert that someone is scanning you.

🛡️ Your Server Withstood It… This Time

Take a close look: many of the attack requests returned a 403 Forbidden or a 404 Not Found. Fortunately. But all it takes is one poorly configured leak to open the door.

The future of your systems depends on what you do today. Don’t wait to see a GET /.env with a 200 OK in your logs to take action.