Accounts, zones, and least-privilege tokens
Separate user, account, and zone scopes, then create a task-specific Cloudflare API token.
Edited and verified by Orange Book Editorial Team ·
Locate the resource first
| Scope | Examples | Common mistake |
|---|---|---|
| User | Login identity and personal tokens | Treating personal power as app authorization |
| Account | Workers, D1, and R2 resources | Selecting the wrong similarly named account |
| Zone | DNS, WAF, and cache settings for a domain | Guessing zone permissions from account permissions |
Token permissions are scoped to user, account, or zone resources. A safe token narrows both the action and the resources on which that action is allowed.
Create one token per task
State the single job
Write “CI deploys Worker A,” not “a general token we may need later.”
Minimize permissions and resources
Add only what the job requires and limit it to the target account and zone. DNS automation does not need every D1 database; Worker deployment does not inherently need zone administration.
Inject it safely
Store the token in a CI secret or local secret store. Example files contain only a placeholder:
CLOUDFLARE_API_TOKEN=<set-in-secret-store>Test the denied path
Run a read-only check first, then the task. Confirm that the token cannot access an out-of-scope resource. Record purpose, owner, and rotation date.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.