Signing up for Cloudflare and enabling the orange cloud gives you network-layer DDoS protection and some default WAF rules. It does not give you rate limiting on your API endpoints, custom WAF rules for your specific application, bot management tuned to your traffic patterns, or origin protection for the IP addresses Cloudflare is proxying for. The gap between "we have Cloudflare" and "our application is protected" is where the majority of L7 DDoS attacks succeed against Cloudflare customers.
In DDactic assessments of organizations using Cloudflare, the most common finding is not that Cloudflare is misconfigured -- it is that the customer-specific configuration layer is simply absent. Default settings protect against generic, undirected attacks. Targeted attacks require targeted configuration.
Default Settings: What You Get
Cloudflare's default configuration on a newly onboarded zone includes: DDoS Attack Protection (automatic, always on), the Cloudflare Managed Ruleset (Web Application Firewall), HTTPS redirection, and basic bot fighting (JavaScript challenge for very low bot scores). What you do not get by default: rate limiting rules, custom WAF rules for your application's specific paths, page rules for caching or bypass, authenticated origin pulls verification, or any configuration of connection timeout behavior.
The Origin IP Exposure Problem
A common Cloudflare misconfiguration is that the origin server IP address is discoverable through DNS history, certificate transparency logs, or SPF records that list the same IP. When an attacker discovers the origin IP, they bypass Cloudflare entirely by sending requests directly to the IP. All Cloudflare protections -- DDoS mitigation, WAF, rate limiting -- are bypassed. DDactic checks this in Stage 1 and Stage 3 of the scan pipeline. Approximately 40% of Cloudflare-protected origins we assess have a discoverable direct-access path.
Check your origin firewall
Your origin server's firewall should allow inbound connections on ports 80/443 only from Cloudflare's published IP ranges. If it accepts connections from any source IP, Cloudflare can be bypassed by any attacker who discovers your origin IP.
Rate Limiting: Not Included by Default
Cloudflare rate limiting is a separate product that requires explicit rule creation. The free tier includes basic rate limiting; Business and Enterprise tiers provide the Ruleset Engine with more flexible expressions. A zone with zero rate limiting rules configured has no per-endpoint protection against application-layer DDoS regardless of which Cloudflare plan it is on. DDactic finds this in roughly 60% of assessed organizations using Cloudflare -- the WAF is active but rate limiting is absent or limited to a single high-threshold global rule that an attacker can stay under.
WAF Managed Rules vs. Custom Rules
Cloudflare's managed ruleset protects against generic web attack patterns: SQLi, XSS, LFI. It does not protect against application-layer DDoS targeting your specific API paths. Custom rules must be written for your application. An API at /api/v2/search that triggers expensive database queries needs a custom rate limiting rule scoped to that path with a threshold appropriate for its processing cost. The managed ruleset will not create this rule automatically.
Configuration Audit Checklist
- Origin IP not in DNS history, CT logs, or SPF records
- Origin firewall restricts inbound 80/443 to Cloudflare IP ranges only
- Rate limiting rules exist for each high-cost API endpoint
- Auth endpoints have per-IP rate limits under 10 requests per minute
- Bot Management or Bot Fight Mode enabled (not just default)
- Authenticated Origin Pulls configured (mutual TLS to origin)
- Custom error pages for 429/503 return JSON for API clients
Audit Your Cloudflare Configuration
DDactic checks all of the above -- plus active rate limit threshold verification -- and reports what is missing.
Run a Free Scan