Sign inBook a Demo

How To

Cloudflare Automation Starts Here: 6 Zone Config Messes to Find First

Cloudflare automation fails when nobody understands the zone: page rules from 2021 nobody dares delete, DNS records without owners, WAF skip rules that outlived their incidents, and settings drifting between zones. Part one of our Cloudflare series maps the six places zone config rots — legacy page rules, dangling DNS, stale WAF exceptions, settings drift, unreviewed security events, and the four signals that actually matter (origin 52x errors, WAF spikes, cert expiry, unexpected DNS changes) — each with a read-only API command or dashboard path to detect it, plus a checklist for what healthy zone hygiene looks like.

ST
·
cloudflareautomationsecuritydnswafdevops
Cover Image for Cloudflare Automation Starts Here: 6 Zone Config Messes to Find First

Cloudflare Automation Starts Here: 6 Zone Config Messes to Find First

Somewhere in your Cloudflare dashboard there is a page rule from 2021. It forwards something, or bypasses cache for something, or disables security for a path that may not exist anymore. Nobody remembers who created it. Nobody knows what breaks if it goes. So it stays — rule 7 of 23, silently matching (or not matching) production traffic on every request.

That rule is why most Cloudflare automation efforts stall before they start. You can't automate a zone you don't understand, and after a few years of hand edits, most zones are archaeology: layered rules, unowned DNS records, WAF exceptions that outlived their incidents, and settings that drifted apart between zones that were supposed to be identical.

This guide maps the six places Cloudflare configuration rots, how each one happens, and one real command or dashboard path to detect it. Everything runs read-only against the Cloudflare API with a scoped token — nothing here changes your zones.

This is part one of a three-part series. Part two is a hands-on guide to DIY Cloudflare automation with the API and native tools; part three covers running Cloudflare operations with an AI agent.

For the commands below, set three environment variables: CF_API_TOKEN (create a read-only token under My Profile → API Tokens), ZONE_ID, and ACCOUNT_ID (both on the zone's Overview page, right sidebar).

1. Page rules nobody dares touch

What it is. Page Rules were Cloudflare's original per-URL configuration mechanism, and Cloudflare has been migrating them to modern Rules (Redirect Rules, Cache Rules, Configuration Rules) since 2024. Most zones older than a couple of years carry both generations at once: legacy page rules underneath, modern rules on top, with subtly different matching and ordering semantics.

Why it happens. Page rules are ordered and first-match-wins, so the safe move was always to add a new rule rather than edit an existing one. Multiply by every redirect campaign, cache experiment, and "temporarily disable security here" incident since the zone was created.

How to detect it. Dump every active page rule with its target, actions, and last-modified date:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/pagerules?status=active" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq '.result[] | {id, target: .targets[0].constraint.value,
      actions: [.actions[].id], modified_on}'

Then list the modern rulesets living alongside them:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq '.result[] | {name, phase, last_updated}'

Any page rule not modified in over a year is a candidate for the migration review. In the dashboard: Rules → Page Rules versus Rules → Overview.

Typical impact. The direct cost is incident time: stacked rules with overlapping URL patterns are a classic source of "cache didn't purge" and "redirect loop in production" tickets, and the debugging session routinely burns half a day because nobody knows which of 20 rules fired.

2. DNS records without owners

What it is. A records pointing at IPs that were released years ago. CNAMEs targeting SaaS trials the company abandoned. TXT verification records for tools nobody uses. A busy zone accumulates hundreds of records, and typically nobody can say who owns half of them.

Why it happens. Adding a DNS record takes 30 seconds and unblocks someone immediately. Deleting one carries unbounded downside — so nothing is ever deleted. Cloudflare's DNS records have no owner field and no expiry, and marketing, engineering, and IT all write to the same zone.

How to detect it. Export the full record set and sort by last-modified:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?per_page=500" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq -r '.result[] | [.type, .name, .content, (.proxied|tostring), .modified_on] | @tsv' | \
  sort -t$'\t' -k5

Flag three things: unproxied A/AAAA records exposing origin IPs that should sit behind the proxy; CNAMEs pointing at third-party hostnames that no longer resolve (dig each target — a dangling CNAME to a deprovisioned SaaS endpoint is the setup for a subdomain takeover); and anything untouched for 2+ years with no owner anyone can name.

Typical impact. Dangling records are a genuine security exposure, not just clutter — subdomain takeover via abandoned CNAMEs remains one of the most commonly reported findings in bug bounty programs.

3. WAF exceptions that never expire

What it is. WAF rules cut both ways. Custom rules block traffic; skip rules and exceptions let traffic through. During an incident — a false positive blocking a customer, a partner integration tripping a managed rule — someone adds a skip. The incident ends. The skip stays, permanently exempting an IP range, path, or user agent from inspection.

Why it happens. Exceptions are created under pressure and removed by nobody. There is no expiry mechanism on a WAF exception, and six months later nobody remembers whether the partner still needs it.

How to detect it. Pull the zone's custom WAF rules and isolate anything with a skip action:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/phases/http_request_firewall_custom/entrypoint" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq '.result.rules[] | select(.action == "skip") |
      {description, expression, last_updated}'

In the dashboard: Security → WAF → Custom rules, plus the exceptions list under the managed rules tab. Review every skip against a question with a real answer: what breaks today if this is removed?

Typical impact. Each stale exception is an unmonitored hole in the exact layer you deployed to be monitored. Teams doing a first review typically find that a meaningful minority of their WAF rules — often a quarter or more — reference IPs, paths, or partners that no longer exist.

4. Settings drift between zones

What it is. You run 12 zones that are "configured the same." They aren't. One is on SSL mode Full while the rest are Full (strict). Two have minimum TLS 1.0 because a legacy client needed it in 2022. Browser Integrity Check is off on the zone where someone debugged a webhook once.

Why it happens. Zone settings are edited one dashboard toggle at a time, usually during an incident, and there is no built-in "diff these zones" view. Every hand edit is a fork.

How to detect it. Snapshot each zone's settings to a file and diff:

for Z in $ZONE_A $ZONE_B; do
  curl -s "https://api.cloudflare.com/client/v4/zones/$Z/settings" \
    -H "Authorization: Bearer $CF_API_TOKEN" | \
    jq -r '.result[] | [.id, (.value|tostring)] | @tsv' | sort > "settings-$Z.tsv"
done
diff settings-$ZONE_A.tsv settings-$ZONE_B.tsv

Prioritize the security-relevant deltas: ssl (anything below strict means Cloudflare doesn't validate your origin certificate), min_tls_version, always_use_https, and security_level.

Typical impact. Drift converts every incident into a scavenger hunt — "works on zone A, fails on zone B" with no obvious reason. The weakest zone also sets your actual security posture, regardless of how well the flagship zone is configured.

5. Security events nobody reviews

What it is. Cloudflare logs every WAF match, challenge, and block to Security → Events (24–72 hours of retention on self-serve plans, queryable via the GraphQL Analytics API firewallEventsAdaptive dataset). On most accounts, nobody has opened it since the last incident.

Why it happens. The WAF is sold as set-and-forget, and on a quiet day the events feed is noise. But the feed is where you'd see a credential-stuffing run being challenged, a scanner mapping your API, or your own false positives blocking real customers — days before any of those becomes a ticket.

How to detect it. Open Security → Events, set the range to 7 days, and group by rule. Two findings matter: rules firing thousands of times (either an attack pattern worth escalating from challenge to block, or a false positive silently hurting users) and managed rules that have never fired (candidates to tighten). Ten minutes weekly is enough — the problem is that nobody's calendar contains those ten minutes.

Typical impact. Reviewed-never WAF logs are how teams learn about a three-week-old credential-stuffing campaign from their users instead of their firewall.

6. The signals that matter, unwatched

What it is. Four things on Cloudflare genuinely warrant immediate attention: origin errors (edge status codes 520–526 mean Cloudflare can't talk to your origin properly), WAF event spikes, certificate expiry — on the origin side and for edge certificate packs — and unexpected DNS or configuration changes.

Why it happens. Teams alert obsessively on their origin infrastructure and not at all on the layer in front of it. Cloudflare will happily serve 526 (invalid origin certificate) to every visitor while your origin-side dashboards stay green.

How to detect it. Origin errors: Analytics & Logs → Traffic, filter edge status codes to the 520–526 band. Certificate expiry:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/ssl/certificate_packs" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq '.result[] | {type, status, expires_on: .certificates[0].expires_on}'

Unexpected changes: the audit log records every mutation with actor and timestamp:

curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/audit_logs?since=$(date -u -v-7d +%Y-%m-%dT%H:%M:%SZ)" \
  -H "Authorization: Bearer $CF_API_TOKEN" | \
  jq '.result[] | {when, actor: .actor.email, action: .action.type, resource: .resource.type}'

(On Linux, use date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ.)

Typical impact. These four signals cover the large majority of Cloudflare-layer incidents. Watching them turns "the site is down and we don't know why" into "cert expires Thursday, renew it Tuesday."

What healthy zone hygiene looks like

A zone in good shape has properties you can verify, not vibes:

  • Every DNS record has a nameable owner; nothing dangles.
  • Zero legacy page rules, or a dated migration plan for each survivor.
  • Every WAF skip rule answers "what breaks if this goes?" with something current.
  • Zone settings match a written baseline, and drift is diffed on a schedule.
  • Security events get ten minutes of human attention weekly.
  • Origin errors, WAF spikes, cert expiry, and audit-log anomalies page someone.

The catch is the word schedule. Every dashboard edit, incident exception, and quick DNS fix regenerates the mess, so a one-time cleanup decays back to sprawl within a couple of quarters. The teams that stay clean make the checks continuous — part two of this series builds exactly that with the Cloudflare API, scoped tokens, and Notifications, no third-party tools required.

Keep the checks running without keeping an engineer on them

Everything above is scriptable — and CloudThinker runs it for you. Connect Cloudflare with a read-only scoped API token and CloudThinker agents continuously inventory your zones, DNS, WAF rules, and settings drift, correlate security events with recent config changes, and surface findings before they become incidents — with any fix gated behind your approval. Try CloudThinker free — 100 premium credits, no card required — or continue with the DIY automation guide.