Fastly credentials: Contain Leaked API Tokens Before Your Edge Changes

A leaked Fastly API token with global scope can change the configuration that sits in front of your websites and APIs, which means an attacker could redirect traffic, alter responses or purge caches without ever touching your origin. Fastly tokens are often created once for a deployment pipeline or a Terraform provider and then forgotten, and the default lifetime for automation tokens is 90 days but can be set to never expire. This guide covers Fastly's token types and scopes, how roles limit who can mint them, how to spot a leaked token and its misuse in the audit log, and the revoke and rotate steps from Fastly's documentation. It is written for platform, SRE and security teams that run services on Fastly. For the generic process read the Leaked Credential Response Playbook, and for edge architecture the CDN Security Guide.

Key takeaways

• Scope decides the damage. A global token can change and activate service configuration; global:read, purge_select and purge_all are far narrower, so find the scope before you size the incident.
• Automation tokens outlive people. They are account-level credentials for CI and pipelines, created only by superusers, and keep working when staff leave.
• Tokens cannot be edited. Fastly tokens are immutable, so the fix for an over-scoped or leaked token is always create new, redeploy, delete old.
• The audit log is superuser-only. It records token creation, logins, service configuration changes and version activations for 365 days, filterable by token ID.
• Last-use data is per token. The token API returns last_used_at, ip and user_agent, which quickly shows whether a leaked token has been used from somewhere unfamiliar.

How identity and access work in Fastly

Fastly's API authenticates with a token sent in the Fastly-Key HTTP header. Every token is owned by a user: legacy account API keys from before 15 May 2017 were migrated to a global token owned by a synthetic user named "Global API Token", which is worth searching for in older accounts. There are two token types:

Scopes and service restrictions set what a token can do:

A token can be limited to selected services or service groups; an empty services list in the token API means all services on the account. Combining a narrow scope with a service restriction is the single most effective way to limit what a leaked token can do. See the API Key Management Guide for the general model.

Admin roles and privileged access

Service-level permissions for engineers and users run Read-only, Purge select, Purge all and Full access, each including the previous level; only Full access can change configuration and activate new versions. New services are not reachable by users and engineers without Full access until a superuser grants a level. Every user can manage their own personal tokens whatever their role, so token sprawl grows with headcount. Treat the superuser tier as privileged access, as the Privileged Access Management Guide describes.

Integrations, API tokens and service accounts

Choosing a token

When company-wide two-factor authentication or forced single sign-on is enabled, tokens cannot be created through the API and must be created in the control panel. That is a useful control: a stolen token cannot simply mint more tokens through the API. Store every token in a secrets manager because the token string is shown only once, at creation. The Terraform and IaC Pipeline Credential Security Guide covers provider tokens in pipelines.

Logging and detection

Spotting a leaked token

Fastly tokens have no published fixed prefix, so scanners rely on context. GitHub secret scanning supports fastly_api_token in public repositories as a partner pattern (GitHub reports the finding to Fastly) and in private repositories with GitHub Advanced Security, with push protection and validity checks. Fastly's documentation does not say what Fastly does with partner reports, so do not wait for it. The Gitleaks default rule fastly-api-token matches a 32-character value near the word "fastly", so tokens stored under neutral names such as CDN_KEY will be missed; add a rule for your variable names. See the Git Secret Scanning Guide.

Misuse signals

• Token last use: GET /tokens (your own) and GET /customer/{customer_id}/tokens (all tokens on the account) return last_used_at, ip and user_agent. A leaked pipeline token last used from an unfamiliar IP address or a desktop user agent is a strong signal.
• Audit log: superusers view it at Account, Audit log, filtered by event type, token ID, service ID, user ID and date, or pull it with GET /events. Events include API token creation, web logins, service configuration changes, account security setting changes and version activation (version.activate). Records keep the acting user, IP address and metadata for 365 days.
• Service event log: each service page shows its last 20 service events, including who activated the current version; useful for a quick check during triage.
• Edge behaviour: unexpected purges, cache hit ratio drops, new backends or domains, and configuration versions that do not match your repository.

Metrics

• Number of global tokens with no service restriction, trending to zero.
• Tokens set to never expire, and tokens older than your rotation period.
• Tokens with no use in 90 days (from last_used_at) and their removal rate.
• Version activations not matched to a pipeline run.
• Time from secret scanning alert to token deletion.

Leak response: revoke and rotate

1. Identify the token: list account tokens with GET /customer/{customer_id}/tokens and match by name, owner, creation date and last use. Note its scope, services and whether TLS management is set.
2. Create the replacement first if it is a pipeline token: a superuser creates a new automation token with the narrowest scope and service list, stores it in the vault and updates the pipeline. Skip this if the risk is high enough to accept a broken deployment.
3. Delete the leaked token: in the control panel at Account, API tokens, click the trash icon and Delete, or call DELETE /tokens/{token_id}. A user can revoke their own tokens; superusers can revoke other users' tokens. Deletion is immediate and breaks any integration that uses the token.
4. Review what it did: filter the audit log by the token ID from the earliest exposure, looking for configuration changes, version activations, new tokens and security setting changes. Check last use IP and user agent.
5. Restore known-good configuration: if versions were activated by the attacker, activate the last known-good version and diff it against your repository. Check backends, domains, VCL, logging endpoints and TLS settings.
6. Check follow-on credentials: any token created during the exposure window, and any logging endpoint added (which could stream request data elsewhere), must be removed.
7. Clean the source and record the cause: remove the token from history, CI logs and images. Use the Secrets Rotation Runbook Template for evidence fields.

Sizing the incident

Not every Fastly token leak needs the same response. Use what the token API and audit log tell you to decide how far to go.

Where an unrestricted global token belonged to a superuser, also review account security settings and user invitations in the audit log, because the token carried the same account-level access as its creator. If the token was an engineer's personal token, ask the engineer whether their machine is the source of the leak, and treat their control panel session and password as possibly exposed too. For large estates, a pre-agreed severity table like this one lets an on-call engineer act at night without waiting for a superuser to assess every finding.

Hardening baseline

1. Inventory: pull all account tokens, flag global scope without service restrictions, never-expiring tokens, the "Global API Token" synthetic user and tokens unused for 90 days.
2. Replace, do not edit: because tokens are immutable, re-issue narrow automation tokens per pipeline, deploy them, watch for 401 errors, then delete the old ones.
3. Enforce 2FA or SSO: this also blocks token creation through the API.
4. Limit superusers: only superusers create automation tokens and read the audit log, so the group must be small and reviewed.
5. Use service permissions: give engineers Full access only on the services they own.
6. Ship the audit log: poll GET /events into your SIEM so detection does not depend on someone logging in.
7. Roll back safely: if a new narrow token breaks a job, issue a correctly scoped one rather than reviving the old broad token.

Small teams can stop at one restricted automation token per pipeline with 90-day expiry, enforced 2FA and secret scanning. Larger organisations should manage services as code, alert on any version activation not tied to a pipeline run, and review tokens quarterly.

Common misconfigurations

• A single global token for everything: purging, dashboards and deployments sharing one full-control token.
• No service restriction: an empty services list gives the token every service on the account.
• Never-expiring automation tokens: the 90-day default exists for a reason.
• The legacy "Global API Token" left in place: a pre-2017 key migrated to global scope that nobody owns.
• TLS management on deployment tokens: grants certificate control across all services when the job needs none.
• Audit log never reviewed: it is superuser-only, so without SIEM ingestion few people ever see it.

Framework mapping

Practitioner checklist

• List all account tokens and record scope, services, expiry, owner and last use.
• Replace unrestricted global tokens with narrow, service-limited automation tokens.
• Remove never-expiring tokens and the legacy "Global API Token" if unused.
• Enforce company-wide 2FA or SSO.
• Keep the superuser group small and review it quarterly.
• Ingest the audit log into your SIEM and alert on version activations outside pipelines.
• Add scanner rules for Fastly tokens stored under neutral variable names.
• Rehearse restoring a known-good service version after a token leak.

Standards and references

• Fastly: Managing account-level API tokens
• Fastly: User tokens API reference
• Fastly: API tokens overview
• Fastly: About user roles and permissions
• Fastly: Monitoring account activity with the audit log
• GitHub Docs: Supported secret scanning patterns
• NIST: SP 800-53 Rev 5, Security and Privacy Controls

Related NHI Mgmt Group resources: CDN Security Guide · Leaked Credential Response Playbook · API Key Management Guide · Secrets Management Guide