Managed Rules Know the Internet. Custom Rules Have to Know Your Application.

A managed ruleset is written by people who have seen a great many attacks and have never seen your application. That is exactly why it is good at stopping what is common to every site, and why it cannot make the decisions that depend on what normal looks like for you. The practical question is where the line falls, and which handful of custom rules is worth writing on your side of it.

What the managed layer really does

Cloudflare's WAF ships vendor-maintained rulesets. In broad terms there are two styles.

The first is a signature-style ruleset maintained by Cloudflare's own team. It targets known exploit patterns and specific vulnerabilities in widely used software. Its biggest practical benefit is speed: when a serious vulnerability in a popular framework or product is disclosed, a rule for it often arrives before you have finished patching. You get that protection without doing anything.

The second is an implementation of the OWASP Core Rule Set. It works by scoring. Each matching rule adds to a request's anomaly score, and the request is acted on when the total crosses a threshold. You control the sensitivity (how many rules participate) and the threshold (how much evidence is needed). This makes it broader and also more prone to false positives.

Together these cover the generic injection and traversal families well: SQL injection, cross-site scripting, command injection, path traversal, known bad payloads and scanners. For those, the right amount of custom work is close to zero. Turn the managed rules on, in the strongest action your traffic tolerates, and keep them updated automatically.

What no generic rule can know

The managed layer inspects requests for patterns that look malicious. Many real attacks do not look malicious at all. Each request is well formed. The abuse is in the intent, the volume or the sequence.

The first two rows are where a managed ruleset earns its cost. Everything below depends on knowledge only you have: what your login volume is, who your partners are, which endpoints are expensive, which paths the public should never touch.

One row deserves emphasis. A WAF does not fix broken authorization. If your API returns another customer's invoice when the ID is changed, no edge rule reliably saves you. That one is fixed in code.

False positives are a cost, not a nuisance

Every blocking control has two error types. It can let an attack through, or it can stop a legitimate request. Teams measure the first and ignore the second, because the second produces no alarm. A blocked customer just sees an error page and leaves.

For a revenue-bearing application, a blocked checkout or a failed partner integration often costs more than the low-grade probes the rule was stopping. So tuning against false positives is part of the job, not polish.

The discipline is to make exceptions as narrow as the problem. Picture a wholesaler whose ERP posts order batches to /api/v1/import, and the payload contains free-text notes that trip an injection signature. The wrong fixes are common: disabling the managed ruleset, or lowering sensitivity for the whole zone. The right fix is an exception that skips the specific offending rules, only for that path, only for that method, and only from the partner's addresses. In Cloudflare's rule language the match would look something like this:

(http.request.uri.path eq "/api/v1/import"
 and http.request.method eq "POST"
 and ip.src in $partner_ips)

Three conditions, one path, one named list. Everything else in the zone keeps full protection. Write the reason and the ticket number in the rule description, because in a year nobody will remember why it exists.

A few habits keep exceptions from eroding the baseline:

• Skip individual rules or tags, not whole rulesets, when the tooling allows it.
• Prefer identifying the caller (mutual TLS, a signed header, a known address list) over trusting a path alone.
• Re-test exceptions when the partner or the endpoint changes.
• Count your exceptions. A growing list is a signal that the sensitivity setting is wrong for your traffic.

Rate limits: designed per endpoint, revisited on a schedule

Rate limiting is where custom work is unavoidable, because there is no universal correct number. A sensible limit for a login form is absurd for an image path and far too loose for a password reset.

Design each limit by answering four questions:

1. What is being protected? A specific path and method, not the zone.
2. What is the counting key? Client IP is the default and the weakest. Offices, universities and mobile carriers put thousands of users behind one address. Where your plan allows it, count by something closer to the actor: a session cookie, an API key header, or a combination.
3. What does legitimate peak use look like? Take the busiest real client over the last few weeks and set the limit comfortably above it.
4. What happens on a hit? A challenge is forgiving for browsers. A block with a clear status code is right for APIs. Choose a mitigation duration that is short enough to recover from a mistake.

For login in particular, counting failed attempts is better than counting all attempts. Where the platform lets you count on response status, a limit of a few failed logins per minute per client barely touches real users and slows credential stuffing dramatically. Pair it with leaked-credential detection, which flags login attempts using username and password pairs known from public breaches.

Then there is the failure that turns a rate limit into an outage. A limit tuned during a quiet month meets a product launch, a television mention or an email campaign that worked. Traffic triples, exactly as hoped, and the edge starts refusing customers. The control is behaving as configured. The configuration is stale.

Protect against it procedurally:

• Review limits against real traffic every quarter and before every planned campaign.
• Put marketing launches on the engineering calendar, with a named person watching mitigation counts during the first hour.
• Alert on the ratio of rate-limited requests to total requests on critical paths.
• Favor per-client limits over global ones, so growth in the number of users does not look like abuse.

Bots: a score does nothing until a rule acts on it

Bot detection assigns each request a likelihood of being automated. On the tiers that expose it, the score is available as a field you can match on. The important point is that a score by itself is only a number in a log. Protection comes from a rule that reads it and takes an action.

That rule should be specific. A blanket "block everything that looks automated" breaks your own monitoring, payment provider callbacks, partner integrations and the search engine crawlers you want. A better shape is:

(http.request.uri.path contains "/checkout"
 and cf.bot_management.score lt 30
 and not cf.bot_management.verified_bot)

with a challenge as the action, tightened to a block once you have watched who gets caught. Different paths deserve different postures: strict on checkout and account creation, relaxed on public content, explicit allowances for your own automation.

DDoS: the baseline is on, the residual work is yours

Cloudflare's DDoS mitigation runs automatically for proxied traffic, across network, transport and application layers, and it is not metered by attack size. You do not need to configure it to receive the baseline. That is true, and it leads teams to stop thinking too early. What remains is specific to you.

Close the back door. If your origin accepts connections from anywhere, an attacker who learns its address (from old DNS records, certificate logs, an email header) can skip the edge entirely. Restrict the origin firewall to the proxy's published address ranges, or better, connect the origin outbound through a tunnel so it has no public listener at all. Authenticating the edge to the origin with a client certificate adds a second lock.

Protect the expensive requests. Volumetric floods are the platform's problem. A low-rate attack that sends a few hundred requests per second to your slowest search endpoint is yours, because each request is valid and each one costs you a database query. Caching, rate limits and challenges on costly endpoints are the defense.

Tune the automatic rules when they misfire. The managed DDoS rules can be overridden: sensitivity lowered or action changed for a specific rule. This matters for traffic that legitimately looks like a flood, such as a fleet of devices that all report in at the top of the hour, or a mobile app that retries aggressively after an outage. Fixing the client is the durable solution. The override buys time.

Know what is not proxied. Standard proxying covers HTTP and HTTPS. Other TCP and UDP services, and protection for your own IP ranges, are separate products. A DNS record set to bypass the proxy exposes whatever it points to.

Have an attack-day plan. Know who can enable a heightened challenge mode, what it does to API clients (it will break non-browser traffic), and how to turn it off.

Roll out like a deployment

A rule that blocks traffic is a production change. Treat it that way.

1. Observe first. Deploy in a non-blocking mode where your plan supports one, or use a challenge action, and read the matches for several days covering a full business cycle.
2. Know the evaluation order. Custom rules, rate limiting rules and managed rules run in distinct phases, and a skip action in one affects what later phases see. Draw the order once and keep the drawing.
3. Keep rules in version control. Managing the configuration through the API or an infrastructure-as-code tool gives you review, history and a one-step rollback. Changes made by hand in a dashboard at midnight are how rules end up fighting each other.
4. Fewer, sharper rules. Twenty overlapping rules written by five people are harder to reason about than six with clear descriptions. Delete what no longer matches anything.
5. Review on a cadence. Monthly, look at the top rules by matches and the rules with zero matches. Both lists are informative.

A starter set of custom rules

Most applications are well served by the managed baseline plus a short list:

• Restrict admin and internal paths to identified users or networks.
• A rate limit on login, counting failures.
• A rate limit on password reset and account creation.
• A limit or challenge on each expensive endpoint.
• Narrow exceptions for known integrations that trip managed rules.
• A bot rule on the one or two flows that are worth abusing.
• Origin locked to the proxy.

That is seven items, and each one comes from knowing your own traffic.

Which of your current rules would you defend if someone asked why it exists?

If the honest answer is "about half", the ruleset needs a review against real traffic before it needs anything new. Trivo implements WAF and DDoS configuration starting from a traffic review, so every rule has a reason and an owner. Bring your ruleset and a week of logs, and you will leave knowing which entries earn their place, which ones only add noise and which can be deleted outright.