Application-layer security isn't just input validation — the network edge in front of your app is where most attacks are stopped or missed. Here's how I configure Cloudflare and a WAF for production apps.
A well-written application is still exposed if the edge in front of it isn't configured. Cloudflare and a properly tuned WAF handle an entire class of attacks before they ever reach your servers.
Turn on WAF rules in "log" mode before "block" mode. A misconfigured rule that blocks real users is worse than the attack it was meant to stop.
Not all bots are hostile — legitimate crawlers (Googlebot, Bingbot, and AI crawlers like GPTBot and ClaudeBot) need to reach your content for SEO and discoverability. Configure bot rules to challenge or block credential-stuffing and scraping bots specifically, rather than blanket-blocking all automated traffic.
Strict-Transport-Security: max-age=63072000; includeSubDomains
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
These headers stop entire attack classes (clickjacking, MIME sniffing, some XSS vectors) for effectively zero runtime cost.
Cloudflare's network-level DDoS mitigation is largely automatic once traffic is proxied — the engineering work is making sure origin servers aren't directly reachable, and that rate limiting protects expensive endpoints (search, uploads, report generation) that a volumetric attack would target specifically.
Edge security and application security are complementary, not interchangeable — a WAF catches what your code shouldn't have to, and your code should never assume the WAF caught everything. I configure both layers together as part of any production deployment.
I'm Sandaruwan Jayasundara — Senior Software Engineer | Cloud & DevOps. See AWS cloud architecture for startups or get in touch about securing your infrastructure.