What a WAF is and what it cannot stop, and why Cloudflare's DDoS protection only covers traffic that passes through it. Plus locking down the origin, false positives and who owns the rules after go-live.
On the day the team switched DNS so the system ran through Cloudflare, the progress report could say "the system now has a WAF and DDoS protection." Half of that sentence is true. If the origin server still accepts requests from anyone on the internet, the other half is not. A WAF is a filtering layer for HTTP requests placed in front of the system, and Cloudflare can defend against DDoS only for traffic that travels through its network. This article is written for IT leads and system owners who have to tell a committee what sits in front of the system and what it actually protects. We separate what a WAF can and cannot do, explain how DDoS protection works at different layers, and name the decisions that need an owner after go-live.
What a WAF is, and what it cannot stop
OWASP defines a WAF as an application firewall for HTTP applications that applies a set of rules to the HTTP conversation, and says those rules typically cover common attacks such as Cross-site Scripting (XSS) and SQL Injection (source: OWASP, Web Application Firewall). A network firewall decides on IP address and port. A WAF reads the content of the request, such as the path, headers and body, and compares it with attack patterns. Cloudflare's WAF is a service of this kind that runs on Cloudflare's network before a request reaches the origin, so it only sees requests that pass through the proxy.
The limit is here. A WAF recognizes what a dangerous request looks like, but it does not know your system's business rules. If a user changes a document number in a URL and opens another agency's document, that request looks perfectly normal, and there is no pattern for the WAF to catch. A system that lets the person who files a request approve their own request, or a session that stays valid after logout, belongs to the same group. Flaws in access control, authentication and business logic have to be fixed in the code and in the permission design, not in front of the system.
What a WAF does well is buy time. When a vulnerability in a library is announced and the team cannot patch it yet, a rule matching that pattern lowers the chance of an attack while you wait. The vulnerability is still in the system. For that reason we do not treat a WAF as a reason to postpone fixes for findings from a penetration test.
The two work together. Neither replaces the other.
How DDoS protection works: know which layer is under attack
A DDoS attack needs to be thought of in two layers. The first is the network and transport level (layers 3 and 4), where a flood of packets or connections fills the pipe or the connection table. You cannot fix this layer on your own server, because by the time the traffic reaches the machine the pipe is already full. Protection has to happen on a network larger than the attack, before the traffic arrives.
The second is the application level (layer 7), where each request looks like a real user. For example, a search page that runs a heavy database query might be hit tens of thousands of times. The volume of data may be small, but every request forces the origin to do real work. Cloudflare describes its HTTP DDoS Attack Protection managed ruleset as a set of pre-configured rules that detect known layer 7 DDoS attack patterns. It is always on, and the user can adjust only its behavior: the action taken when an attack is detected, and the sensitivity of detection (source: Cloudflare, HTTP DDoS Attack Protection).
The same documentation contains advice that public sector teams should read. If you expect a large surge of legitimate traffic, consider adjusting the DDoS protection settings so that real traffic is not classified as an attack. Picture a hypothetical agency that opens benefit registration at nine in the morning, with many people clicking in during the first minute. That pattern looks a lot like a layer 7 attack. If nobody tells the team that manages the configuration in advance, settings that protect the system on an ordinary weekday could keep real users out on the day they need it most. The documentation also notes that some actions or sensitivity levels may not be available on every plan, so check what your current plan lets you change before that day.
Cloudflare protects only the traffic that passes through it
Cloudflare's WAF troubleshooting page states plainly that Cloudflare can mitigate only the requests that are part of traffic proxied through it. Its checklist for attacks that reach the origin asks, in the last item, whether malicious traffic is going straight to the origin's IP and bypassing Cloudflare's protection. It recommends blocking all traffic at the origin except traffic from Cloudflare's IPs (source: Cloudflare, Troubleshoot managed rules). In executive terms: if someone learns the real IP of the machine, the money spent on the WAF can be walked around immediately.
The real IP can leak in several ways. Examples are an old DNS record that points straight at the machine from before the move to Cloudflare, a subdomain used for staging or for sending email that is not proxied, or an older system that used the same IP. Hunting down every way an IP might leak is work that never ends. The better question is not whether the IP has leaked, but whether the origin would accept a request that arrives that way if it had.
Cloudflare's documentation on protecting your origin gives several options and states the trade-off of each (source: Cloudflare, Protect your origin server). The three we see as the main decision points are these.
Allowlist Cloudflare's IPs on the origin's firewall. The documentation rates this as moderate security. You set an allowlist of Cloudflare's IP ranges at the origin, and it notes a risk from IP spoofing. This is the fastest to start, because it uses firewall rules on Google Cloud or Microsoft Azure that the team already knows. Someone has to check regularly that the list still matches what Cloudflare publishes.
Authenticated Origin Pulls verify that requests reaching the origin really come from Cloudflare's network. The documentation rates this as high security, but it requires the Full or Full (strict) encryption mode and extra server-side setup such as uploading a certificate. The certificate becomes one more item that needs an owner.
Cloudflare Tunnel has the origin open a single outbound connection to Cloudflare's network, so the machine's IP is never exposed. The documentation rates this as high security. It requires installing a daemon called cloudflared on the origin machine or virtual machine. This approach moves the burden from firewall rules to one process that has to be monitored and updated.
We do not think any one of these is right for every system. The criterion we use is which team will keep running the mechanism after the developer hands the work over. If the organization's infrastructure team manages cloud firewalls every day, an allowlist may last longer than a Tunnel that nobody remembers installing on some machine. Whichever you choose, if the old IP has already leaked, locking the origin closes the route for requests that bypass the WAF, but network-level traffic aimed directly at that IP can still reach your cloud provider's network. Deciding whether to change the origin's IP after the lock is done is worth settling at the same time.
Managed rules and false positives: watch the results before you block
A managed ruleset is a set of ready-made rules that the provider maintains and updates for you. Turning it on takes a few clicks, but the effect on real users starts with the first request. Cloudflare defines a false positive as a legitimate request that was detected and handled as if it were an attack. In an enterprise system, the places to watch are forms that submit HTML from a rich-text editor, search boxes or report filters that accept long text, and file uploads. That data can resemble an XSS or SQL Injection pattern even though it is ordinary staff work.
So we recommend watching the results before you block. If your tooling has a log-only mode, start there. If it does not, start with a narrow scope, such as one hostname with few users, and read the security events across a full working cycle of the organization, such as month-end close or the annual filing period, not just the first couple of days. Those are the periods when rarely used forms actually get opened.
When you find a false positive, the guidance on the same troubleshooting page is to add an exception that skips the rule for certain requests, adjust the OWASP ruleset settings, or disable only the rule that is causing the problem rather than the whole ruleset. We add one point: every exception should be narrow, naming both the path and the rule, with a reason and the approver's name attached. The same page's checklist for attacks that get through asks whether managed rules are being skipped by an exception. A broad exception added last year to fix an urgent problem is the kind of opening nobody remembers.
Rate limiting is a different tool from DDoS protection
Rate limiting sets a ceiling on the number of requests in a period for requests that match a condition, and defines an action when the ceiling is exceeded. It pays off on endpoints where each request has a cost or carries risk, such as a login page that gets password guessing, an OTP page where every send costs an SMS, or an API that external systems call. The tool answers over-use by individual callers. It is not designed to absorb an attack distributed across a large number of sources.
The trap to think through ahead of time in a government or enterprise setting is that a whole office may reach the internet through one IP. A ceiling counted per IP could block an entire floor of staff at once on a morning when everyone logs in. The ceiling should come from traffic you have measured, not a number chosen by feel, and you should know which partner agencies or branches share an IP in large numbers.
Who owns the rules after go-live
OWASP notes that WAF tuning needs ongoing maintenance as the application changes. That means every release that adds a form or an endpoint can trigger a new round of false positives. There are four questions to answer before go-live. When a real user is blocked, who do they call? Who has authority to approve an exception? Who reads the security events regularly? And who holds admin rights on the Cloudflare account?
The last one is the same issue as any cloud account. The Cloudflare account should be in the organization's name and have its permissions reviewed like any other account, which we describe in our article on who actually holds the keys to your cloud account. If rule tuning is outsourced, write it into the contract scope with a response time for when users are blocked, following the approach in our checklist for annual maintenance contracts (in Thai). If a WAF event needs to wake someone at night, route it into the same alerting system the team already uses, following the principles in our article on monitoring and alerts, instead of a separate channel nobody opens.
The drawback to state plainly is that a strictly tuned WAF will block real users at some point, and rule tuning is a monthly burden that does not end when the project closes. If the organization cannot yet name an owner for this work, we suggest starting with a narrower rule set and getting the origin locked down first. A strict WAF that nobody maintains risks being switched off entirely on the day users complain, which is worse than a basic rule set that stays on.
An objection we hear often
A common objection is that the system is behind Cloudflare now, so the remaining flaws in the code can wait for the next round. The reasoning is understandable, because the development team's time is limited, and a WAF does reduce risk for attacks with a clear pattern. But the permission and business logic flaws described above get past a WAF because they look like ordinary requests. And if the origin still accepts requests directly, every flaw remains reachable without passing the WAF at all. We see a WAF as a layer that lowers risk while a fix is pending. The development team is still the one that closes the vulnerability, and it should get time for that work in the plan.
Where to start
If we had to put the order in again from the beginning, we would close the side routes before tuning rules, because a rule, however good, means nothing if requests can walk around it.
List all of the organization's hostnames, and separate the records that are proxied through Cloudflare from the records that point straight at a machine.
Test from an outside network whether the origin still answers requests sent directly to its IP. If it does, choose a way to lock the origin and name the team that will maintain that mechanism.
Turn on managed rules in a mode or scope that lets you watch the results first. Read the security events across one real working cycle, then switch to blocking.
Set rate limiting only on endpoints that cost something per request, such as login and OTP, using numbers from real traffic.
Tell the team that manages Cloudflare in advance of any day when many users are expected to arrive at once.
Write the names of the rule owner, the exception approver and the account's admin holder into the handover documents.
Summary
The Cloudflare WAF and DDoS protection defend only what passes through them, and filter only what has a pattern to catch. If you take one thing from this article, check whether the origin of your important systems still accepts requests directly from the internet. The answer tells you how true the sentence "the system has a WAF" in your report really is.
If your organization is putting Cloudflare in front of an existing system, or already has a WAF but is not sure who owns the rules, and would like someone to review it with you, we are happy to talk. There is no deadline and no need to decide quickly.
To talk through the details of a project, you can reach us at 088-983-9386 or [email protected]. Our office is in Bangkapi, Bangkok. More about us is at superdev.tech. For organizations reviewing how the front of their system is set up, we are glad to start with a conversation to understand the problem first, and if we find that what you already have is enough, we will say so plainly.
FAQ: Frequently Asked Questions about This Article
A collection of questions and answers to help you better understand the content of this article.
Tags: