TL;DR
A firewall rule we set up months ago and forgot about blocked over 50,000 malicious requests in a single night. The attack targeted SQL injection and XSS vulnerabilities. Our basic Cloudflare WAF rules caught everything. This is a story about how basic security measures pay off when you least expect it.
I almost didn't check the Cloudflare dashboard that morning. But something made me look, and what I saw made me very glad we'd spent 30 minutes setting up basic firewall rules months earlier.
The Attack We Slept Through
Between 2 AM and 8 AM, someone had launched a sustained automated attack against our application. The requests were a mix of SQL injection attempts, XSS payloads, and path traversal attacks.
"I remember setting up those Cloudflare rules on a Friday afternoon, thinking 'this is probably overkill for our small app.' Six months later, they saved us while we were literally asleep."
What the Attack Looked Like
The blocked requests included payloads like:
// SQL Injection attempts
/api/users?id=1' OR '1'='1
/search?q='; DROP TABLE users;--
/login?user=admin'--
// XSS attempts
/comment?text=<script>alert('xss')</script>
/profile?name=<img onerror="fetch('evil.com')">
// Path traversal
/files?path=../../../etc/passwd
/download?file=....//....//config.php
All of these were blocked by our basic WAF (Web Application Firewall) rules before they ever reached our server.
The Rules That Saved Us
We'd enabled these basic Cloudflare protections:
- OWASP Core Ruleset: Catches common attack patterns like SQLi and XSS
- Bot Management: Blocked known malicious bot signatures
- Rate Limiting: Max 100 requests per minute per IP
- Challenge Mode: For suspicious traffic patterns
// Example Cloudflare firewall rule (expression)
(http.request.uri.query contains "UNION SELECT") or
(http.request.uri.query contains "DROP TABLE") or
(http.request.uri.query contains "../") or
(http.request.uri.query contains "<script")
What Worked
- Default WAF rules caught 90% of attacks
- Custom rules for our specific endpoints caught the rest
- Rate limiting prevented the attack from scaling
- Attack logging gave us full visibility after the fact
- Zero impact on legitimate users during the attack
Why Basic Protection Matters
This attack wasn't sophisticated. It was automated scanning looking for low-hanging fruit. The attacker was probably hitting thousands of sites hoping some wouldn't have basic protections.
If we hadn't had those firewall rules:
- SQL injection attempts would have hit our database layer
- Even if our code handled them safely, the load would have been significant
- We might have spent days investigating potential breaches
- Our logs would have been full of noise, hiding real issues
Instead, we slept peacefully and checked a dashboard in the morning.
- Basic security measures block the majority of automated attacks
- WAF rules take 30 minutes to set up and work 24/7
- Free tiers of Cloudflare/similar services provide substantial protection
- Defense in depth means you can sleep while attacks bounce off
- Logging and visibility help you understand what you're facing
Is Cloudflare's free tier enough for basic protection?
For many small to medium sites, yes. The free tier includes basic WAF rules, DDoS protection, and SSL. Paid tiers add more customization and advanced bot management, but free is a huge improvement over nothing.
Can firewall rules cause false positives?
Yes, overly aggressive rules can block legitimate users. Start with standard rulesets, monitor for false positives, and tune as needed. Most WAFs let you whitelist specific patterns or IPs if needed.
Do I still need secure code if I have a WAF?
Absolutely. WAFs are a layer of defense, not a replacement for secure coding practices. Think of them as a filter that catches obvious attacks, but you should still validate input, use parameterized queries, and follow security best practices.
Set Up Your Defenses
Scan your vibe coded projects for vulnerabilities before attackers find them.
Check Your Vibe Now