On this page9 sections
Short answer
What does a Cloudflare account audit cover?
A Cloudflare account audit reviews six areas: TLS and edge, DNS exposure, application security, performance, Zero Trust, and account governance. Each finding gets a severity and an effort estimate, so the first fixes are the few that are both high-impact and cheap. Changes then ship in phases, starting in observe mode where the plan allows it.
Who this is for: teams that inherited a Cloudflare account, run many zones, or have not reviewed their settings since the first deployment. This is the audit method we run. The accounts we review are rarely broken in one dramatic way; 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.
How is the data collected?
Through the API, not the dashboard, so every zone is checked the same way. Python scripts collect zone settings, rulesets, DNS and Access configuration, and a few weeks of traffic and security analytics from the GraphQL Analytics API. Templates turn the results into an HTML report for engineers and a workbook for whoever owns the remediation plan. A token with Read permissions is enough for collection.
Documented limits shape what you can see:
- Audit logs (version 2) record create, update, and delete actions across most products, but not read requests. They are kept for 18 months; the dashboard shows the latest 90 days, and the API returns the rest. Logpush exports only from the moment a job exists and cannot backfill.
- Analytics retention. The GraphQL adaptive datasets keep at least 31 days on every plan. Security Analytics keeps up to 31 days on Free, Pro, and Business, and up to 90 days on Enterprise.
- Security Insights, Cloudflare’s own scanner, flags some of the same issues, such as dangling or unproxied records, users without multi-factor authentication, and missing managed rules. Its findings are a useful input; the audit adds the ranking and the rollout order.
The account audit checklist
This is the account audit checklist. It is our method, not a Cloudflare standard.
| Area | Check | What Cloudflare documents |
|---|---|---|
| TLS and edge | SSL/TLS mode per zone, and whether it is Automatic or custom | Flexible sends origin traffic over HTTP; Full does not validate the origin certificate; Cloudflare strongly recommends Full or Full (strict) |
| Minimum TLS version, Always Use HTTPS, HSTS | With HSTS covering subdomains, any subdomain without HTTPS becomes unreachable; per-hostname minimum TLS needs Advanced Certificate Manager | |
| Edge certificate coverage and CAA | Universal SSL does not cover names below the first level; CAA records Cloudflare adds do not show in the dashboard | |
| DNS exposure | DNS-only records pointing at a proxied origin | A DNS-only record returns the origin IP, which lets traffic bypass the WAF |
| Dangling records and DNSSEC status | Security Insights flags dangling records as a subdomain-takeover risk | |
| Application security | Managed rulesets deployed; overrides that quietly disable rules | Free zones get only the Free Managed Ruleset; the Cloudflare Managed Ruleset needs Pro or higher |
| Custom rules: duplicates, rules that never match, broad skip rules | Limits are 5, 20, 100, and 1,000 rules on Free, Pro, Business, and Enterprise; a Block stops later rules | |
| Rate limiting on login, signup, password reset, and expensive API endpoints | Plan-dependent features; see the WAF rollout article | |
| Bot configuration compared with the security events | Bot Management for Enterprise is a paid add-on | |
| Performance | Cache hit ratio by path, and why static content is not cached | A Set-Cookie header or private, no-store, no-cache, or max-age=0 prevents default caching |
| Origin 52x rates over time | Origin Analytics separates origin responses from edge responses | |
| Zero Trust | Over-broad Access policies | An Allow policy that includes Everyone, or Login Methods set to One-time PIN, lets anyone in; Bypass enforces no controls and is not logged |
| Self-hosted apps still reachable directly; Gateway logging and posture checks configured but not enforced | Access is deny by default only for Access applications | |
| Governance | Members and roles against least privilege; SSO and 2FA enforcement | Super Administrators can enforce 2FA for all members; dashboard SSO is available on all plans |
| API tokens: scope, expiry, IP restrictions; any Global API Key use | Tokens support resource scoping, a TTL, and client IP filtering; the Global API Key is legacy and not recommended |
The severity and effort model
We call this the severity and effort model. It is the model published in the author’s audit write-up, not a standard: define your own targets if your change process differs.
| Severity | Typical example | Target |
|---|---|---|
| Critical | Origin IP exposed and reachable; Flexible SSL on a login flow | Days |
| High | Managed rules disabled by an override; over-privileged API tokens | Next change window |
| Medium | Low cache hit ratio on static paths; no rate limiting on authentication | Within the quarter |
| Low | Inconsistent settings between similar zones | With the baseline rollout |
Effort is small (a setting), medium (a rule or policy rewrite that needs testing), or large (an architecture change, such as moving an origin behind a tunnel). Read the two together:
| Small effort | Medium effort | Large effort | |
|---|---|---|---|
| Critical or High | Fix first | Plan this phase | Plan, with an interim control |
| Medium | Fix with the first group | Schedule | Backlog with an owner |
| Low | Batch | Backlog | Backlog |
How are fixes rolled out?
In phases, never as one change. Security changes start in observe mode where the plan supports it: Cloudflare documents the Log action for custom rules as Enterprise-only, so on other plans the new rule is sized from Security Analytics filters and goes live on a narrow scope first. TLS changes go zone by zone, with an origin check before each switch. Anything that touches authentication gets an owner and a rollback step before it starts.
What is the deliverable?
An account a new engineer can understand, change safely, and reason about from code. The last step is a Terraform baseline imported with cf-terraforming, so the account does not drift back. Cloudflare’s import guide generates the configuration, then imports the existing resources into state; until that import runs, Terraform treats them as new. After it, a plan should report no changes.
What this article has not tested
- The model has not been validated against an external benchmark. It ranks findings; it does not score an account.
- Plan differences beyond the ones cited here.
- Third-party audit tools; Security Insights is used only as an input.
- Findings from real accounts are not included, and none will be published.
FAQ
What access does an audit need?
Read-only access through the API is enough for collection: a token with Read permissions, scoped to the accounts and zones in scope, owned by a named person, and given an expiry. Write access is needed only later, for the fixes, and should be scoped to that task. Audit logs do not record read requests, so collection leaves no trace there.
How long are Cloudflare audit logs kept?
Audit logs version 2 are kept for 18 months. The dashboard shows the most recent 90 days, and the API returns the full period. Logpush can send audit logs to your own storage for longer retention, but only from the moment the job is created; it cannot backfill older entries, so set it up before you need it.
Can I audit without an Enterprise plan?
Yes. TLS modes, DNS records, custom rules, Access policies, tokens, and members can all be reviewed on any plan. A few checks depend on the plan: the Log action is Enterprise-only for custom rules, Bot Management is a paid Enterprise add-on, and Security Analytics keeps 90 days on Enterprise instead of 31 days.
Why rank findings by effort as well as severity?
Because severity alone produces a long list that nobody starts. A high-severity finding that is a one-line setting should ship this week; a high-severity finding that needs an architecture change needs a plan and an interim control. Ranking both tells you which is which, and puts the cheap, high-impact fixes in the first phase.
Is the severity model a standard?
No. It is our method, written down so that it can be reviewed and reused, and it does not come from Cloudflare documentation. The targets (days, the next change window, the quarter, the baseline rollout) fit a typical change process. If you adopt the model, set your own targets for each level to match yours.
Sources
Checked against vendor documentation on How the articles are checked
- Audit Logs, version 2
- Logpush
- GraphQL Analytics API limits
- Security Analytics
- Security Insights
- SSL/TLS encryption modes
- Universal SSL limitations
- CAA records
- HTTP Strict Transport Security
- Proxy status
- Managed rules
- WAF custom rules
- Rules language actions
- Bot Management
- Default cache behavior
- Origin Analytics
- Access policies
- Two-factor authentication
- Dashboard SSO
- Create an API token
- Global API key (legacy)
- Import Cloudflare resources
- Cloudflare account audits: from findings to a phased rollout (author’s original write-up)