Case study · Cloudflare fleet security
More than 130 websites sat behind Cloudflare, and DNS, TLS, WAF behavior, access controls, traffic behavior and change discipline had to stay consistent on every one — not just hold on one. This case study sets out what a fleet that size does to edge security, the baseline that answers it, and the method that keeps it from drifting.
Published Last reviewed
The business problem
One Cloudflare zone configured carefully is a solved problem. A hundred and thirty zones are a different kind of problem, because every setting now exists many times over, and each copy can be changed independently by whoever has access that day. The risk stops being a single bad rule and becomes inconsistency: the same fleet protected well in one place and barely at all in the next.
The conditions below are not a list of incidents from this engagement. They are what a fleet of that size creates by default, and they are what the fleet baseline had to answer.
Settings that start identical diverge. A rule relaxed to fix one site’s checkout, a TLS mode changed during a migration, a managed ruleset switched to log-only while debugging — each is reasonable in the moment and none is reverted without a baseline to compare against.
Custom rules and rate limits get written per zone, under pressure, for the attack in front of someone. Across many zones the result is a patchwork where nobody can say which sites have login protection and which do not.
Proxying a hostname hides the origin only if nothing else reveals it. One unproxied record, a mail or FTP subdomain, or an old DNS entry can expose a server — and when several sites share that server, one leak exposes all of them.
Fleets accumulate account members, agency staff, contractors, and API tokens for deploy tools and plugins. Each is an administrative path to the edge, and on a large account they outlive the people and projects that created them.
The fleet baseline
The baseline covered the same control categories the Cloudflare security service reviews today. What changes at fleet scale is that each one has to be defined once and checked everywhere.
| Control | Baseline expectation | Why it matters across many sites |
|---|---|---|
| DNS and proxy inventory | Every record known, with a reason for being proxied or not | An unexplained grey-cloud record is a common way an origin leaks |
| TLS mode | Full (strict) as the goal, with valid origin certificates | A mixed fleet of Flexible and Full modes means some origin legs are unverified |
| Managed WAF | Managed rulesets in enforcing mode, with documented exceptions | Log-only rulesets look identical to enforcing ones until an attack arrives |
| Custom rules | Rules matched to the real WordPress attack surface, not copied blindly | Rules that suit a brochure site can break a store or a membership login |
| Rate limiting | Limits on login and checkout paths where the plan allows | Credential stuffing moves to whichever site in the fleet is unprotected |
| Origin protection | Origin firewalled to Cloudflare ranges or otherwise made unreachable directly | Every edge rule is bypassable while the origin answers direct-to-IP requests |
| Account access | Named members, MFA, and scoped API tokens instead of a global key | A shared or stale credential on the account is access to every zone on it |
| Cache rules | Carts, checkout, accounts and logged-in sessions never cached | One careless cache rule copied fleet-wide can leak private pages everywhere |
| Change discipline | A documented baseline, audit-log review, and scheduled drift checks | Without a reference point, drift is invisible until something fails |
Method
The fleet method: one documented baseline, exceptions recorded rather than improvised, and scheduled drift review. The fleet size is the only figure shown.
Inventory DNS, TLS, WAF state, custom rules, rate limits, members and tokens per zone, and record where each site departs from the baseline — and whether the departure has a reason.
Edge rules are only meaningful once the origin cannot be reached around them, so origin exposure is addressed before rules are tightened.
Move protections from log-only to enforcing in stages, watching real traffic so checkout, login, APIs and legitimate crawlers keep working. Exceptions are written down, scoped to the site that needs them, and never quietly applied fleet-wide.
Record what is configured, why, and who owns each control — including the short list of per-site exceptions — so any administrator can tell intended difference from drift.
Compare each zone against the documented baseline, review the account audit log and the member and token list, and retire access that no longer has an owner.
For a single site
A single WordPress site behind Cloudflare benefits from the same discipline without the scale. The failures that repeat across a fleet — a ruleset left in log mode, an origin still answering its IP, a cache rule that catches the cart — are the same ones that show up on one domain, and they are checked for deliberately rather than discovered by customers.
Fleet work also sets expectations about which rules survive contact with real traffic. Settings that look safe in a dashboard but break a checkout or lock out a payment callback are known in advance, so a single-site review can move to enforcement with fewer surprises.
For agencies with many client zones, the same method scales down or up: one documented baseline, per-site exceptions in writing, and a review cadence agreed with whoever owns each client relationship.
Boundary
Client identity, engagement dates, the client’s sector, zone names, per-site findings and any traffic or blocking figures are withheld. Publishing them would identify the client and describe the configuration of live websites, and public case studies should not provide a map of a former client’s edge.
The source record for this engagement is the public portfolio entry on Upwork, linked below. This page describes the conditions the fleet created, the control categories the baseline covered, and the method used to keep it consistent — it does not claim outcome numbers that are not published there.
Common questions
One standard can; one identical configuration usually cannot. Stores, membership sites and brochure sites need different cache rules, rate limits and exceptions. The workable approach is a shared baseline for TLS, WAF mode, origin protection and account access, plus a short, documented list of per-site exceptions.
By giving drift something to be measured against. Document the baseline, record every intended exception, review the account audit log and member and token list on a schedule, and compare each zone’s current settings with the baseline — through the dashboard or by exporting configuration through the Cloudflare API. Anything that differs and is not recorded is drift.
Not to manage them securely. Many zones can live under one account on any plan, and the core controls — proxying, TLS mode, managed and custom WAF rules, members and scoped API tokens — are available per zone. Some account-level features that deploy one ruleset across many zones, and higher rule and rate-limit allowances, depend on plan tier; check Cloudflare’s current plan documentation before designing around them.
It can be. Proxying hides the origin address in DNS answers, but the server may still be found through unproxied records, historical DNS, mail headers, or internet-wide scans that match a site’s certificate to an IP. Until the origin only accepts traffic from Cloudflare — by firewalling to Cloudflare’s published ranges, authenticated origin pulls, or a tunnel — the edge can be bypassed.
Because the published source record does not state engagement dates, per-site findings or traffic figures, and this page does not invent them. Anything beyond the public record can be shared only where the client relationship allows it.