When should you NOT use API Key Exposure?

Never store API keys in source code, config files tracked by git, or any value that gets logged. Do not use the same key for development and production — a leaked dev key with production scope is a critical exposure. Avoid long-lived keys with broad permissions where short-lived scoped tokens are available.

When is API Key Exposure the right choice?

Apply this threat model when reviewing any code that handles credentials, tokens, or secrets — especially near git commits. Run secret scanning tools (git-secrets, truffleHog, GitHub secret scanning) in CI to catch keys before they reach the remote.

← Back to glossary

API Key Exposure

security CWE-312 OWASP A2:2021 CVSS 9.1 Beginner

debt(d5/e5/b5/t6)

d5 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'specialist tool catches it' (d5). The term's when_to_use field explicitly lists specialist tools like git-secrets, truffleHog, and GitHub secret scanning to catch keys in CI. The detection_hints.automated field says 'no' (meaning no default/built-in detection), but these dedicated secret-scanning tools do catch many cases. However, keys embedded in front-end JS or mobile binaries, or keys in private repos without scanning configured, can go undetected, pushing slightly beyond d5 but not to d7.

e5 Effort Remediation debt — work required to fix once spotted

Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix is vague ('see documentation'), suggesting no simple one-liner. Remediation involves: rotating the compromised key, purging it from git history (BFG or filter-branch across commits), updating all services/environments that reference the key, migrating to a secrets manager or environment variables, and auditing for unauthorized usage. This spans multiple files and systems. For a single hardcoded key it might be e3, but common_mistakes show keys reused across environments and embedded in multiple places, making e5 the realistic anchor.

b5 Burden Structural debt — long-term weight of choosing wrong

Closest to 'persistent productivity tax' (b5). Proper secret management is a cross-cutting concern: every developer, every environment, every CI pipeline, and every deployment must handle secrets correctly. The tags (secrets, authentication, devops) and applies_to (web, cli) show broad reach. It's not quite b7 because it doesn't reshape every code change — but it does impose an ongoing discipline requirement on all team members and workflows, creating a persistent productivity tax if not systematized early.

t6 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'notable trap' (t5), +1 to t6. The misconception field states the core trap: developers believe rotating a leaked key immediately makes them safe, when in reality automated scrapers can capture and use keys within seconds of a public commit. This contradicts the intuitive mental model that 'quick rotation = safe.' Additionally, common_mistakes reveal non-obvious traps: git history permanence (many devs think deleting a file removes the secret), front-end key extraction, and cross-environment key reuse. These compound surprises push slightly above the standard t5 'documented gotcha' anchor.

About DEBT scoring → scored by claude-opus-4-6 · 2026-05-06 · reviewed by human

Also Known As

leaked API key exposed secret hardcoded API key

TL;DR

API keys committed to version control, logged, or exposed in client-side code can be harvested and abused by attackers.

Explanation

API keys grant programmatic access to services and are high-value targets. Common exposure vectors include: committing keys to public repositories, including them in JavaScript bundles served to browsers, logging request URLs that contain keys as query parameters, and insufficient access scoping. Rotate exposed keys immediately, use environment variables and secrets managers, scope keys to the minimum required permissions, and monitor for anomalous usage patterns.

Watch Out

⚠ A key pushed to a public GitHub repo is typically harvested by automated scanners within minutes — rotating the key is the only safe response; assuming "nobody saw it" is not a valid remediation.

Common Misconception

✗ Rotating a leaked key immediately makes you safe. Automated scanners scrape public commits within seconds — the key may already have been used before rotation completes.

Why It Matters

An exposed API key gives an attacker the same access as the legitimate service — often including billing, data access, and write operations — with no secondary authentication required.

Common Mistakes

Committing keys to version control, even briefly — git history is permanent.
Embedding keys in front-end JavaScript or mobile app binaries where they can be extracted.
Using the same key across all environments so a dev leak compromises production.
Not rotating keys immediately upon suspected exposure or team-member departure.

Avoid When

Never store API keys in source code, config files tracked by git, or any value that gets logged.
Do not use the same key for development and production — a leaked dev key with production scope is a critical exposure.
Avoid long-lived keys with broad permissions where short-lived scoped tokens are available.

When To Use

Apply this threat model when reviewing any code that handles credentials, tokens, or secrets — especially near git commits.
Run secret scanning tools (git-secrets, truffleHog, GitHub secret scanning) in CI to catch keys before they reach the remote.

Code Examples

💡 NoteThe bad example hardcodes a live Stripe key in source — once committed it lives in git history even after deletion; the fix reads from an environment variable and the key never touches the codebase.

✗ Vulnerable

// API key hardcoded — visible in git history forever
\$stripe = new \Stripe\StripeClient('sk_live_abc123secret');

// In JavaScript — fully visible in browser
const apiKey = 'sk_live_abc123secret';

✓ Fixed

// PHP — load from environment, never hardcode
\$stripe = new \Stripe\StripeClient(\$_ENV['STRIPE_SECRET_KEY']);

// .env (not committed)
STRIPE_SECRET_KEY=sk_live_abc123secret

// Rotate immediately if leaked — most providers let you invalidate old keys
// Use git-secrets or truffleHog to scan for accidental commits
// Consider Vault or AWS Secrets Manager for team/production secrets

References

↗ https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html