Cloudflare has introduced app‑scoped API tokens for Flagship, allowing a token to be limited to one or more explicitly chosen Flagship applications instead of the entire account. Engineers and security teams can now enforce a finer‑grained permission set for automation, CI pipelines, and server‑side services that only need to interact with a single app.
UI change: selecting a specific Flagship app
When generating a custom token the resource selector now defaults to Entire Account. Switching the dropdown to Specified Flagship apps reveals a list of the account’s Flagship applications. After picking an app, the token can be granted one of three Flagship permissions: Evaluate, Read, or Write. The previous account‑wide Evaluate, Read, and Write options remain for cases where full‑account access is required.
Why the restriction matters to practitioners
Limiting a token to a single app reduces the blast radius if the secret is exposed, aligning with the principle of least privilege. Server‑side environments such as Wrangler, continuous‑integration runners, or backend services often only need to query or update one Flagship app; granting broader access creates unnecessary risk and complicates audit trails.
Operational impact and token lifecycle
Creating an app‑scoped token follows the same workflow as any Cloudflare API token, but the extra step of choosing Specified Flagship apps adds a decision point for permission scope. Practitioners should map each automation job to the minimal required permission (Evaluate for runtime checks, Read for configuration retrieval, Write for updates). Existing automation that currently uses account‑wide tokens should be reviewed and, where possible, replaced with app‑scoped equivalents. The dashboard provides a direct link to the app‑scoped token form for quick migration.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt app‑scoped tokens for any workflow that interacts with a single Flagship app. Audit existing tokens, downgrade permissions where feasible, and update CI/CD pipelines to reference the new, narrowly scoped secrets. This change offers a straightforward way to tighten access without altering application code.
