SecureBlockLog inStart a pentest
Vulnerability Repository
CriticalMisconfiguration

API Key Exposure

Hardcoded or publicly leaked API keys grant attackers authenticated access to third-party services, often with billing and data implications.

CVSS 9.1CWE CWE-200OWASP A02:2021 — Cryptographic Failures

Description

API keys are bearer tokens—whoever possesses the key is granted the associated level of access with no additional identity verification required. When these credentials are hardcoded into source code, committed to version control, bundled into mobile application binaries, or left in publicly accessible JavaScript bundles, they become available to any attacker who looks for them.

CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) captures the core issue: sensitive credentials are made accessible outside their intended security boundary. A02:2021 Cryptographic Failures applies because the secret's confidentiality—a foundational property of any credential—has been broken. The most common vectors include public GitHub repositories, leaked .env files in web roots, JavaScript source maps that include environment variables, and decompiled mobile application binaries.

The blast radius of API key exposure depends on the key's scope. A leaked AWS access key with AdministratorAccess permissions allows complete cloud account takeover. A leaked Stripe secret key allows refund manipulation and data access. Even keys for seemingly minor services (SendGrid, Twilio) can be weaponized for spam campaigns that get the victim's domain blacklisted and result in significant financial liability from service charges.

How It Works

Attackers search for exposed keys using automated tooling against source code repositories, web responses, and cloud storage:

# Search GitHub for exposed keys using truffleHog
trufflehog github --repo https://github.com/example/app --only-verified

# Search for AWS keys in a local repo
git log -p | grep -E "AKIA[0-9A-Z]{16}"

# Scan a deployed web app's JavaScript bundles
python3 - <<'EOF'
import requests, re
r = requests.get("https://example.com/static/js/main.chunk.js")
# Common key patterns
patterns = [r'AIza[0-9A-Za-z\-_]{35}', r'AKIA[0-9A-Z]{16}', r'sk_live_[0-9a-zA-Z]{24,}']
for p in patterns:
    print(re.findall(p, r.text))
EOF

A discovered AWS key can be validated and exploited immediately:

# Validate and enumerate permissions
aws sts get-caller-identity --access-key AKIAIOSFODNN7EXAMPLE \
  --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# List S3 buckets accessible with the key
aws s3 ls --access-key AKIAIOSFODNN7EXAMPLE ...

Tools like gitleaks, truffleHog, detect-secrets, and semgrep automate large-scale scanning. GitHub's own secret scanning program notifies some API providers when keys are committed, but this notification arrives after the commit is public and the window of exposure has already begun.

Impact

  • Cloud account takeover — AWS, GCP, or Azure keys with broad permissions allow compute provisioning, data access, and persistent backdoor creation.
  • Financial liability — Attackers spin up expensive compute instances for cryptocurrency mining; bills run to tens of thousands of dollars before detection.
  • Data breach — Keys for database services, analytics platforms, or storage buckets expose customer PII, financial records, and intellectual property.
  • Service abuse — Communication API keys (Twilio, SendGrid) are used for spam and phishing campaigns at the victim's expense and reputational cost.
  • Supply chain risk — Keys embedded in open-source libraries or CI/CD configurations compromise every downstream consumer of the package.

Detection

  1. Run truffleHog --regex --entropy=False against the full git history of all repositories, including private ones accessible to any team member who may have introduced a leak.
  2. Scan compiled mobile app binaries: decompile Android APKs with apktool and iOS IPAs with class-dump, then grep for key patterns.
  3. Download and analyze all JavaScript bundles served by the application; search for key patterns and base64-encoded strings that decode to credentials.
  4. Check public S3 buckets, Azure Blob containers, and GCS buckets associated with the organization using cloud_enum or s3scanner.
  5. Query Pastebin, GitHub Gists, and code search engines (sourcegraph.com) for the organization's domain name adjacent to credential patterns.
  6. Verify whether discovered keys are still active by making a low-privilege API call—avoid any write or destructive operations during verification.

Remediation

Rotate all exposed keys immediately. The moment a key is confirmed exposed, revoke it and issue a replacement. Do not rely on restricting the key's permissions as a substitute for revocation.

Use secrets management platforms. Store all credentials in HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Inject secrets at runtime via environment variables, never at build time via source code.

Implement pre-commit hooks. Use detect-secrets or gitleaks as pre-commit hooks to block credential commits before they reach the repository. Enforce this in CI/CD pipelines as a mandatory gate.

Apply least-privilege scoping. Scope API keys to the minimum required permissions and, where supported, restrict keys to specific IP addresses or calling services.

Enable automated secret scanning. GitHub Advanced Security, GitLab Secret Detection, and standalone tools like gitleaks in CI provide continuous scanning across all branches and pull requests.

Ready when you are
Scope a pentest in the next two minutes.
Start scoping