Stop Passing Around API Keys

Has this actually caused real problems?

Yes. Repeatedly. At scale.

2023 · CircleCI

Every secret, rotated

A breach forced every CircleCI customer to rotate every secret in their CI environment. Thousands of organizations scrambled to replace API keys across their entire infrastructure — overnight.

2022 · Uber

Hardcoded keys on a network share

An attacker social-engineered past MFA, then found PowerShell scripts containing hardcoded AWS credentials on an internal file share. Those keys unlocked Uber's cloud infrastructure.

2022 · Samsung

Keys in the source code

Lapsus$ leaked SmartThings source code. Buried inside: AWS keys, GitHub tokens, Artifactory credentials — all plaintext, all active.

2021 · Codecov

Supply-chain key exfiltration

Attackers modified Codecov's Bash uploader to silently exfiltrate environment variables — including API keys — from thousands of CI pipelines. Two months before anyone noticed.

2021 · Twitch

125 GB of secrets

Twitch's entire source code was leaked, complete with API keys and credentials scattered throughout. 125 GB of proof that secrets in code are only secret until they aren't.

2018 · Tesla

Kubernetes to cryptomining

Attackers found Tesla's Kubernetes console exposed without auth. Inside: AWS credentials. Used to run cryptominers on Tesla's cloud bill.

The scale of the problem: GitHub detects millions of leaked secrets in public repositories every year. API keys are the #1 type. If your security depends on nobody running git push with a secret in the repo, it has already failed.

What's actually wrong with API keys?

This is not a tooling problem you can patch with secret scanners. API keys are architecturally broken:

No expiration — they live forever unless someone remembers to rotate them
No scoping — one key, full access, all the time
No audit trail — who used this key? When? From where? You'll never know
Leaked in repos — the #1 secret type found in public repositories
Shared secrets — both sides store the same value. Compromise either, compromise both
No standard rotation — every provider does it differently, if at all
No revocation granularity — revoke one consumer's access and break everyone else's

What should I use instead?

User-facing apps — OAuth 2.0 / OpenID Connect. Scoped, time-limited, delegated.
Machine-to-machine (same cloud) — Workload identity. Zero secrets.
Machine-to-machine (cross-boundary) — mTLS, OAuth Client Credentials, or SPIFFE.
Webhooks — HMAC signatures. No bearer credential needed.

Not sure which fits? Use our interactive decision tree.

Has the industry actually moved on?

The biggest cloud providers actively discourage their own API keys:

AWS recommends IAM roles over access keys and flags long-lived keys as a security finding
Google Cloud recommends workload identity federation over service account keys
Azure recommends managed identities and is deprecating shared key auth on storage
GitHub offers OIDC for Actions and fine-grained tokens with expiration

When the providers who issue API keys tell you not to use them, it is time to listen.

"But we've always done it this way"

We also used to telnet into production. We used to FTP deploy by dragging files into a folder. We used to email spreadsheets of shared passwords. The industry moved on from every one of those, and nobody misses them.

API keys had their moment. That moment was 2008. We now have OAuth 2.0, OIDC, workload identity, mTLS, and a dozen standards that don't require you to copy-paste a secret into a .env file and pray.

Stop passing around API keys.