What is an API Key?

Definition

An API key is a static credential (a string, often 32–64 characters) that an application sends with API requests to identify itself to a service. The receiving service validates the key and either authenticates the caller, applies rate limits, tracks usage, or all three.

API keys are simple to generate, simple to use, and simple to leak — which is why they're both ubiquitous and one of the most common breach vectors.

In simple terms:

An API key is a password for an application — easy to use, easy to lose.

---

Why It Matters

• API keys are everywhere — vendor APIs, internal services, CI/CD, scripts, agents.
• They're often hardcoded, committed to repos, leaked via logs, or shared.
• Once leaked, they're hard to rotate at scale.
• Many API keys carry significant authority (full account access).
• They lack modern security properties (no MFA, often no expiry, weak attribution).

---

How API Keys Work

Generation

Service generates random opaque string, stores hash, returns to user.

Distribution

User puts key in app config / environment variable / secrets manager / code.

Use

App sends key in:

• HTTP header (Authorization: Bearer <key> or X-API-Key: <key>).
• Query string (worse — logged in URLs).
• Request body.

Validation

Service hashes received key; compares to stored hash; identifies the key's owner / app; checks scope; applies rate limits.

Lifecycle

• Manual rotation (typically).
• Manual revocation.
• No automatic expiry (often).

---

Common API Key Patterns

Vendor APIs

• OpenAI, Anthropic, Stripe, Twilio, SendGrid, etc.
• Account-level or scoped keys.

Internal Services

• Microservice-to-microservice.
• Often used until federation / mTLS adopted.

CI/CD

• Secrets in CI for cloud, vendor, registry access.

Mobile / Web Apps

• Client-side keys for vendor APIs (client_id only; never client_secret).

Webhooks

• Shared secret to verify webhook signatures.

---

Risks

1. Leakage

• Hardcoded in repos.
• Logged in URLs / errors.
• Shared via Slack / email.
• Exposed via misconfigured CI / S3 buckets.

2. No Rotation

• Issued years ago; never rotated.
• Rotation requires app redeploy / reconfig.

3. Over-Permissioning

• Account-level keys for narrow use cases.
• Vendor often offers scoped keys but defaults to broad.

4. Weak Attribution

• Multiple apps share one key.
• Compromise audit can't identify which app's leak caused it.

5. No Expiry

• Lives forever unless manually revoked.

6. No MFA

• Single factor; no step-up.

7. Replay

• Captured in transit (if HTTP) or at rest, replayable indefinitely.

8. Cost / Quota Abuse

• Compromised vendor key → adversary runs up bill.

---

Real-World Examples

1. AI API Key Leak

OpenAI key committed to public repo; scanner found it; adversary ran up $30K bill in days. Mitigation: secret scanning + budget alerts + vendor scoped keys.

2. Vendor Account Compromise

Twilio account API key leaked via vendor breach. Adversary sent SMS-based phishing at scale. Mitigation: scoped keys; webhook verification; rotation.

3. CI Secret Misconfig

CI secret marked "not protected" (visible in PR builds). Forked PR exfiltrated key via build log. Mitigation: branch / environment-protected secrets; OIDC federation.

4. Stripe Key in Mobile App

Backend Stripe secret accidentally bundled in mobile app. Found via APK reverse engineering. Mitigation: client uses publishable key only; backend uses secret key.

5. Account-Level Key Replaced by Scoped

Vendor offered scoped keys; org migrated; reduced blast radius from "full account" to "single workflow."

---

Modern Alternatives

OAuth 2.0 + Short-Lived Tokens

Workload presents OAuth client_id + client_secret (or federation) → receives short-lived access token → uses for API calls.

Workload Identity Federation (Cloud)

Replace cloud SA keys with WIF.

Managed Identity (Azure)

Replace SP secrets with managed identity.

IRSA (AWS)

Replace AWS access keys for K8s pods.

mTLS

Mutual cert-based auth between internal services.

Signed Requests

HMAC-signed requests with short-lived signature; no long-lived secret in transit.

JWT-Based Service Auth

Workload presents JWT signed by trusted authority; verified by API.

---

Best Practices When You Must Use API Keys

1. Use scoped keys — narrow permissions, narrow resources.
2. Use per-app keys — no sharing.
3. Store in secret manager — never in code.
4. Rotate regularly — automated where possible.
5. Revocation playbook — practiced.
6. Monitor usage — anomalies (geo, time, volume).
7. Cost / quota caps — protect against abuse.
8. Send in headers — never query strings.
9. HTTPS only — TLS in transit.
10. Vendor secret scanning — many vendors scan public repos for their keys.
11. Migrate to OAuth / federation when feasible.

---

Checklist

• All API keys inventoried?
• Stored in secret manager (not code)?
• Per-app, scoped keys?
• Rotation automated?
• Revocation playbook ready?
• Anomaly monitoring on usage?
• Cost / quota caps?
• Headers (not URLs)?
• HTTPS only?
• Vendor secret scanning enabled?
• Migration plan to OAuth / federation?

---

How Forestall Helps

Forestall discovers API keys across cloud, code, and secrets vaults; identifies leakage risk; and recommends modern alternatives.

---

Frequently Asked Questions

Are API keys deprecated?

Not formally — but modern best practice is to prefer OAuth / federation / mTLS. API keys remain common for vendor integrations and simple internal use.

Can I just rotate API keys to be safe?

Rotation reduces window of compromise. Combined with secret manager + anomaly detection, manageable.

What about client-side API keys (mobile / web)?

Use only publishable keys (read-only / client-safe). Never embed secret keys.

How often should I rotate?

Quarterly minimum; weekly / monthly for high-sensitivity. Automate where possible.

Are vendor scoped keys widely available?

Increasingly — Stripe, AWS, Google, OpenAI offer scoped keys. Use them.

---

Conclusion

API keys are simple, ubiquitous, and risky. Where they're necessary, treat them with care: scope narrowly, store in secret managers, rotate regularly, monitor anomalies, cap costs. Where possible, migrate to OAuth, workload identity federation, managed identity, mTLS, or signed requests. Done right, you replace one of the largest credential leak vectors with modern, auditable, short-lived alternatives.