Cloudflare Application Security common mistakes
Cloudflare Application Security · Understand the traps and how to avoid them.
Treating the Web Application Firewall as a signature-only filter and assuming any request that matches no signature is safe to pass, so the candidate answers questions about managed rulesets as if they were pure allow/block lists.
Candidates carry over intuition from older intrusion-prevention products where rules are binary signatures, and they miss that WAF rulesets combine anomaly scoring, sensitivity levels, and per-rule actions that can be tuned independently.
What to do instead
Study how a managed ruleset assigns actions (block, managed challenge, log) per rule and how sensitivity and paranoia levels change which rules fire; practice classifying a request by rule category, score contribution, and configured action rather than by 'matches or does not match'.
Confusing the Web Application Firewall with DDoS mitigation when asked which layer stops a given attack, answering 'WAF' for volumetric floods or 'DDoS' for a SQL injection payload.
Both products sit in front of the origin and both can block traffic, so candidates collapse them into one mental model and ignore the distinction between network/transport volumetric attacks and application-layer exploit attempts.
What to do instead
Anchor each product to the OSI layer and the attack intent: volumetric and protocol floods are absorbed by the DDoS pipeline (L3/L4 and L7 rate-based rules), while payload-level exploits such as injection or cross-site scripting are the WAF's job. For each practice scenario, first name the layer and attack goal, then choose the control.
Assuming that enabling a proxy or CDN automatically hides the origin, and answering that origin IP exposure is solved once DNS is proxied, without accounting for direct-to-origin traffic.
The 'orange cloud' mental shortcut is memorable, and candidates forget that historical DNS records, mail subdomains, and direct IP scans can reveal the true origin, so mitigation must include origin-side controls such as authenticated origin pulls or firewall allowlists.
What to do instead
Memorize the origin-protection layers: proxied DNS, locked-down origin firewall accepting only Cloudflare egress ranges, authenticated origin pulls with client certificates, and rotating any leaked IPs. In questions, check whether the scenario mentions direct-to-origin traffic before declaring the origin hidden.
Treating Bot Management as a simple user-agent blocklist, so the candidate answers that blocking the 'bad' user-agent string stops automated traffic.
User-agent spoofing is trivial and candidates over-index on a visible, easy-to-inspect header instead of behavioral and fingerprint signals such as TLS/JA3/JA4 fingerprints, machine-learning scores, and heuristics.
What to do instead
Learn the scoring model: a bot score from 1 (automated) to 99 (human), plus detection sources like machine learning, anomaly detection, verified bots, and heuristics. Practice deciding an action by score threshold and by whether the bot is verified (for example, a search engine crawler) versus unverified.
Conflating 'challenge' actions, answering that a JavaScript challenge and a managed challenge are interchangeable, or that a challenge blocks the request outright.
The action names sound similar and all appear to 'stop' traffic, but they differ in who is interrupted, how much friction is added, and whether the request is blocked or merely required to prove humanity.
What to do instead
Build a comparison table of actions: block (deny), managed challenge (Cloudflare decides the challenge type based on signals), JS challenge (browser must run JavaScript), interactive challenge (user solves a puzzle), and log (observe only). Then map each to the scenario's tolerance for false positives and user friction.
Answering DDoS questions as if mitigation only begins at the origin, describing firewall rules on the server rather than the anycast network absorbing and scrubbing traffic before it reaches the origin.
Candidates picture a single server and a firewall in front of it, missing the distributed anycast architecture and the automatic always-on detection that operates at the network edge.
What to do instead
Study the traffic path: anycast routes the attack to the nearest data center, where L3/L4 protections and L7 rules apply before traffic ever reaches the origin. In scenario questions, ask 'where in the path is this control applied?' and prefer edge-layer answers for volumetric attacks.
Ignoring the difference between rate limiting and DDoS protection, answering that a rate-limiting rule alone mitigates a large-scale flood.
Both count requests, so candidates treat rate limiting as a synonym for DDoS mitigation and overlook that rate limits are per-scope (IP, session, path) and are a complement to, not a replacement for, volumetric absorption.
What to do instead
Separate the tools by purpose: volumetric absorption handles bandwidth floods, while rate-limiting rules cap request frequency for specific paths or identifiers and are tuned to avoid throttling legitimate bursts. For each scenario, identify whether the attack is bandwidth-driven or request-frequency-driven before selecting a control.
Treating TLS termination and encryption settings as irrelevant to web security questions, answering that traffic is 'encrypted end to end' once HTTPS is enabled at the edge.
Candidates equate HTTPS at the browser with full-path encryption and forget the edge-to-origin leg, which can be plaintext or weakly encrypted depending on the SSL/TLS mode and origin certificate configuration.
What to do instead
Learn the SSL/TLS modes (off, flexible, full, full strict) and what each implies for the edge-to-origin hop. In questions, verify whether the scenario requires strict validation of the origin certificate before answering that the connection is secure end to end.
Misreading the shared-responsibility split for security features, answering that enabling a WAF or Bot Management removes the need for input validation, patching, or secure coding on the origin.
Managed security products create a false sense of completeness, and candidates forget that edge controls reduce but do not eliminate the need for secure application design and origin hardening.
What to do instead
Frame edge controls as defense in depth: they filter malicious traffic but do not fix vulnerable code. For each control, state what it covers and what remains the origin's responsibility, and choose answers that keep input validation, patching, and least privilege in place.
Assuming all bot traffic is malicious and answering that Bot Management should block every non-human request, including verified crawlers and monitoring agents.
The word 'bot' carries a negative connotation, and candidates miss that verified bots (search engines, uptime monitors, payment providers) are allowlisted by identity and that over-blocking harms SEO and operations.
What to do instead
Classify bots before choosing an action: verified bots by known identity, likely-automated traffic by low score, and human traffic by high score. Practice selecting allow for verified bots and challenge or block only for unverified automation, and note that bot scores are probabilistic and require threshold tuning.