Cloudflare account permissions, how to use them, and best practices
Access control in Cloudflare is built around two core concepts: roles, which are named bundles of permissions, and scope, which defines the resources those permissions apply to. Every API call to Cloudflare requires a certain set of permissions, otherwise it returns a 403. Permissions are grouped into roles so that a user or token can be granted everything needed to work with a product or fulfill a job function.
Two entities can be assigned roles: a user, which is a profile typically tied to an email address, and a token, which delegates a subset of a user’s permissions for programmatic use.
Roles and scopes available today
When a user signs up, they are given a Cloudflare user and an account. Accounts serve as the traditional resource boundary: permissions granted at the account level apply to all zones and other resources within that account. Inside an account, though, you have zones, R2 buckets, Workers, and other resources. You can now scope access to a selective number of zones, or create tokens with access only to specified R2 buckets.
For most users, the account-level role model is the simplest to work with. There are currently 40+ roles that grant access to a capability across the entire account, with no further scoping. These roles can be viewed under the scope of All domains.
When you only want to grant access to specific zones, domain-scoped roles are the better fit.
Granting explicit scope to one or more domains implicitly denies access to all others. If you routinely need to grant access to multiple domains together—say, all staging zones—you can create a domain group and manage it under Configurations → Lists in the Manage Account page.
A good practice is to create domain groups that reflect similar sets of domains so the group can be reused for every user who needs that access.
Best practices for assigning memberships
Cloudflare’s permissioning model is fail closed and additive: if access is not explicitly granted, it does not exist. Roles are combined additively, and multiple roles can be assigned within a given scope. Cloudflare recommends avoiding “exclusions” whenever possible, as they complicate permission processing.
Take a billing administrator as an example. The cleanest setup is to explicitly grant the Billing and Analytics roles, rather than granting broad access and then trying to carve out web administration permissions.
Two improvements are rolling out to support finer-grained control. The first is the ability to stack multiple policies on a single user—for instance, one set of permissions for development domains and an elevated set for staging domains. The second is expanding scoping beyond accounts and zones. Today you can already specify R2 tokens with access limited to certain buckets, and Cloudflare is experimenting with applying scoping to other object types.
Best practices for token-based access
Interactive users are one thing, but many organizations rely on programmatic access. Cloudflare recommends using API Tokens wherever possible, since they can be scoped down to a smaller subset of a user’s access rather than inheriting all of it.
When building a token’s permissions, you have the same scoping options as with membership roles: account-level scoping and domain or zone-level scoping.
Currently, programmatic access is managed on a per-user basis and is always bounded by that user’s access level. A new capability, being rolled out to all users, lets you restrict API access either account-wide or per user. This toggle appears on the members page for Super administrators. Cloudflare recommends leaving this functionality turned off unless you specifically want to grant API usage to selected users—something that can also be controlled per user via a dropdown. Some organizations have already used this capability to centralize API token creation into a single service user.
What to expect next
The goal is to make role assignments flexible enough to support the least privilege necessary. Recent changes include many capability-specific roles and the option to lock down API access. Upcoming improvements include assigning multiple policies to individual users and adding more scoping options for resources beyond zones and accounts. All current roles are available to every user today.
