Method

Cloudflare account audits: from findings to a phased rollout

Most Cloudflare accounts I review are not badly configured. They are configured in layers: a rule added during an incident, a setting copied from an old zone, a token created for a script nobody runs any more. An audit turns that history into a short, ranked list of changes and a safe order to make them in.

Eduard Agopyan · Network Security Architect

How the data is collected

Configuration is pulled through the API rather than read from dashboards, so every zone is checked the same way. Python scripts collect zone settings, rulesets, DNS and access configuration, plus a few weeks of traffic and security analytics from the GraphQL API. Jinja2 templates turn the results into an HTML report for engineers and an Excel workbook for whoever owns the remediation plan.

What gets checked

TLS and edge

• SSL/TLS mode per zone. Flexible means the origin leg is plain HTTP; Full without strict does not validate the origin certificate.
• Minimum TLS version, HSTS settings, Always Use HTTPS, and edge certificate coverage for every proxied hostname.

DNS exposure

• DNS-only records that point at the same origin as proxied ones. They leak the origin IP and let attackers bypass the WAF entirely.
• Dangling records pointing at deprovisioned cloud resources, a common subdomain-takeover path.
• DNSSEC status and CAA records.

Application security

• Whether the managed rulesets are deployed, and which overrides have quietly disabled important rules.
• Custom rule sprawl: duplicates, rules that never match, and broad skip rules that exempt more than intended.
• Rate limiting on login, signup, password reset and expensive API endpoints.
• Bot configuration compared with what the security events actually show.

Performance

• Cache hit ratio by path, and the reasons static content is not cached: Set-Cookie on assets, no-store from the origin, or cache keys fragmented by tracking parameters.
• Origin error rates (52x) and their pattern over time.

Zero Trust

• Access applications with overly broad policies, such as "any email from the identity provider".
• Self-hosted apps that are protected by Access but still reachable directly on the origin.
• Gateway logging and device posture checks that are configured but not enforced.

Account governance

• Members and roles against least privilege, and SSO or 2FA enforcement.
• API tokens: scope, expiry, IP restrictions, and any legacy Global API Key usage.
• Audit and notification settings, so the next change is visible to someone.

Ranking the findings

Each finding gets a severity and an effort estimate. The report leads with the few items that are both high-impact and cheap to fix.

Rolling out the fixes

Fixes ship in phases rather than as one change. Security changes start in observe mode wherever the plan supports it; TLS changes go zone by zone with an origin check before each switch; and anything that touches authentication gets an owner and a rollback step. The end state is a Terraform baseline, imported with cf-terraforming, so the account stays consistent after the audit instead of drifting back.