Problem
Within hours of deploying MindInChess, Cloudflare's access logs showed a flood of requests hitting paths that didn't exist — /admin, /wp-login.php, /.env, random port numbers, and API endpoints I'd never built. No real users yet, but automated scanners were already probing for open ports and known vulnerability paths.
Key Insight
The internet is continuously scanned. The moment a domain resolves to a public IP, automated bots start testing it. Cloudflare sits in front of the origin server and is the right place to stop this traffic before it reaches the app.
Two settings made the difference:
1. Restrict exposed ports at the Cloudflare level
Cloudflare only proxies specific ports by default, but it's worth auditing which are enabled and disabling anything not in use. My Flask API ran on one port — everything else got blocked at the edge.
2. Create firewall rules for known bad patterns
In Cloudflare's WAF, I added rules to block requests matching:
- Known scanner paths (
/.env,/wp-admin,/phpmyadmin,/config.json) - Requests with no
User-Agentheader - Requests with
User-Agentstrings matching common scanner tools
The origin server never saw these requests at all.
Takeaway
Application-layer security (rate limiting, input validation) is necessary, but edge-layer filtering is faster and cheaper — it blocks scanner traffic before it consumes any compute. Set up Cloudflare firewall rules on launch day, not after you notice the traffic.