Cloudflare
D API / API tokens
The Cloudflare API runs on static bearer tokens that, by default, never expire. They are at least well scoped, fully manageable over the API, show last use, and get revoked when they leak to GitHub. Logpush writes to your S3 or GCS bucket without a key, but the R2 migration tools still ask you to paste AWS access keys.
Docs: developers.cloudflare.com · Checked 2026-09-16 · source YAML · dispute via PR
Inbound D
How a workload running anywhere authenticates to this product.
Static API token (user-owned or account-owned service principal) scoped by permission group and resource, with optional TTL and client-IP restriction. No OIDC or token exchange for API calls.
- developers.cloudflare.com checked 2026-09-16
“The token secret is only shown once. Do not store the secret in plaintext where others can access it.”
- developers.cloudflare.com checked 2026-09-16
“Account API tokens allow you to set up durable integrations that can act as service principals with their own specific set of permissions.”
- developers.cloudflare.com checked 2026-09-16
“Global API key is not recommended for new customers. Current customers using Global API key are encouraged to migrate and use API tokens instead.”
Cloudflare's OIDC support is all on the Access / Zero Trust side (humans and apps behind Access) and in Workers; nothing we could find lets a workload trade an external OIDC token for Cloudflare API access. The legacy Global API Key is an unscoped, non-expiring master key and should be treated as radioactive.
Outbound B
How this product reaches into your cloud, repos, or other SaaS.
Logpush is keyless: you grant a Cloudflare-owned IAM principal (S3 bucket policy) or service account (GCS bucket IAM) write access. R2 Super Slurper and Sippy migrations want a static IAM access key or GCP service-account JSON key, with a documented least-privilege policy.
- developers.cloudflare.com checked 2026-09-16
“Cloudflare uses Amazon Identity and Access Management (IAM) to gain access to your S3 bucket.”
- developers.cloudflare.com checked 2026-09-16
“Cloudflare uses Google Cloud Identity and Access Management (IAM) to gain access to your bucket. The Cloudflare IAM service account needs admin permission for the bucket.”
- developers.cloudflare.com checked 2026-09-16
“Cloudflare recommends you create a user with a narrow set of permissions.”
- developers.cloudflare.com checked 2026-09-16
“"Action": ["s3:ListBucket*", "s3:GetObject*"]”
Logpush's S3 principal is arn:aws:iam::391854517948:user/cloudflare-logpush and the GCS one is [email protected]; you never hand Cloudflare a secret. Super Slurper and Sippy have no IAM-role or federation option, only access keys and JSON keys, so the surface lands at B.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | A TTL (expires_on / not_before) can be set per token, but the default is never and we found no account-level policy that forces one, which the rubric counts as a fail.
|
| ✓ Rotation via API | Both user-owned and account-owned tokens can be created and deleted via the API. Creating or updating an account-owned token requires Super Administrator on the account.
|
| ✓ Scoped keys |
|
| ✓ Last-used visible |
|
| ✓ Leak revocation | Cloudflare is a secret-scanning partner for account API tokens, user API tokens and the Global User API Key, so leaked tokens are reported to Cloudflare for revocation.
|
Notes
Inbound D with 4 of 5 hygiene checks. The one miss, expiry, is the one that matters most: a Cloudflare token minted today with no TTL is valid indefinitely. The dashboard "Roll" action rotates a token in place but is dashboard-only per the docs.
Badge
[](https://wif.tax/p/cloudflare-api/)