How to Check If Your API Key Is Exposed Online

An exposed API key is one of the fastest paths to a data breach. Attackers scan public repositories, client-side JavaScript, and misconfigured servers around the clock. Here is exactly how API keys get leaked, how to check if yours are exposed, and what to do about it.

Why Exposed API Keys Are a Critical Threat

API keys are the passwords of the machine world. They grant access to cloud infrastructure, payment processors, databases, email services, and more. Unlike human passwords, API keys are often granted broad permissions and rarely rotated. When one leaks, the blast radius can be enormous.

In 2025, GitHub reported that over 15 million secrets were detected in public repositories in a single year. GitGuardian's State of Secrets Sprawl report found that 1 in every 10 code authors exposed a secret. The problem is not slowing down — it is accelerating as teams adopt more third-party services, each requiring its own set of credentials.

The consequences of an exposed API key depend on what it unlocks. A leaked AWS key can spin up cryptocurrency mining instances costing thousands per hour. A leaked Stripe key can process fraudulent charges. A leaked Twilio key can send SMS messages at your expense. A leaked database connection string can expose every customer record you have.

How API Keys Get Leaked

1. Committed to Git Repositories

This is the most common source of API key leaks. A developer hardcodes a key during local testing, commits it, and pushes to a public (or even private) repository. Even if the key is removed in a later commit, it remains in the Git history forever unless the history is rewritten.

# The classic mistake - hardcoded key in source code
import requests

API_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"  # DO NOT DO THIS
response = requests.get(
    "https://api.stripe.com/v1/charges",
    headers={"Authorization": f"Bearer {API_KEY}"}
)

Automated scanners like TruffleHog, GitLeaks, and GitHub's own secret scanning service continuously crawl repositories for patterns that match known API key formats. Attackers run the same tools.

2. Exposed .env Files

Environment files (.env) are designed to keep secrets out of source code. But they frequently get exposed through misconfigured web servers, accidental Git commits (missing .gitignore entry), or backup files left in public directories. A simple HTTP request to https://example.com/.env can reveal every secret your application uses. Read our detailed guide on the dangers of exposed .env files.

3. Client-Side JavaScript

Any API key embedded in frontend JavaScript is visible to every visitor. Browser DevTools, view-source, and automated scrapers can extract keys from bundled JS files in seconds. This includes keys in:

• Webpack/Vite bundles that include process.env variables
• Inline <script> tags with configuration objects
• JavaScript source maps that expose the original source code
• Mobile app binaries (APK/IPA files can be decompiled)

4. Server Misconfiguration

Misconfigured servers can expose API keys through directory listings, debug pages, phpinfo() output, error messages with stack traces, or publicly accessible configuration files. A server that returns detailed error messages might include database connection strings or API credentials in the stack trace.

5. Logs and Monitoring Systems

API keys passed as URL query parameters get logged by web servers, proxies, CDNs, and browser history. Keys in HTTP headers can appear in access logs if the logging configuration is too verbose. Even error tracking services like Sentry can capture and store API keys from request data.

6. Third-Party Services and Paste Sites

Developers sometimes paste code snippets containing API keys to Stack Overflow, Pastebin, Gist, or Slack channels. These become indexed by search engines and archived by web crawlers. A key posted to a public Slack channel or Discord server is effectively published to the internet.

How to Check If Your API Keys Are Exposed

Step 1: Scan Your Repositories

Start by scanning your Git history for any committed secrets. These tools check every commit, not just the current state:

# Using TruffleHog to scan entire Git history
trufflehog git file://./your-repo --results=verified

# Using GitLeaks
gitleaks detect --source ./your-repo --report-path results.json

# Using GitHub's built-in secret scanning (for GitHub repos)
# Go to Settings > Code security and analysis > Secret scanning

Run these scans on every repository in your organization, including private ones. A compromised developer account could expose private repo contents.

Step 2: Check Public Sources

Search for your organization's API keys on public sources:

• GitHub Search: Search for your company name, domain, or known key prefixes in public repos
• Google Dorking: Use queries like site:pastebin.com "your-api-prefix" or "your-domain.com" API_KEY
• Shodan/Censys: Search for exposed configuration endpoints on your infrastructure
• Have I Been Pwned: Check if your domain appears in known breach datasets

Step 3: Scan Your Web Properties

Check your live websites and APIs for accidental exposure. Test common paths that often leak secrets:

# Test for exposed environment files
curl -s https://yourdomain.com/.env
curl -s https://yourdomain.com/.env.backup
curl -s https://yourdomain.com/.env.production

# Test for exposed config files
curl -s https://yourdomain.com/config.php
curl -s https://yourdomain.com/wp-config.php.bak
curl -s https://yourdomain.com/web.config

# Test for debug endpoints
curl -s https://yourdomain.com/phpinfo.php
curl -s https://yourdomain.com/debug
curl -s https://yourdomain.com/server-status

Or skip the manual work entirely — the SecureBin Exposure Checker tests all of these paths and more in a single scan.

Step 4: Audit Client-Side Code

Inspect your frontend JavaScript bundles for embedded secrets:

# Download and search your JS bundles
curl -s https://yourdomain.com/main.js | grep -iE "(api_key|apikey|secret|token|password|aws_|sk_live|pk_live)"

# Check source maps if available
curl -s https://yourdomain.com/main.js.map | python3 -m json.tool | grep -i "key"

Step 5: Monitor Continuously

One-time checks are not enough. Set up continuous monitoring:

• GitHub Secret Scanning: Enable push protection to block commits containing secrets
• Pre-commit hooks: Use tools like pre-commit with detect-secrets to catch leaks before they reach the repository
• CI/CD pipeline scans: Add secret scanning to your build pipeline
• Domain monitoring: Regularly scan your web properties for exposed files

What to Do When You Find an Exposed Key

If you discover an exposed API key, treat it as a security incident. Speed matters — automated bots scan for new key leaks within minutes of publication.

1. Revoke the key immediately. Do not wait. Go to the service provider's dashboard and revoke or regenerate the key. Most providers (AWS, Stripe, Google Cloud, etc.) allow instant key rotation.
2. Generate a new key and update it in your secure secrets management system (AWS Secrets Manager, HashiCorp Vault, environment variables on your deployment platform).
3. Audit the damage. Check the service provider's logs for unauthorized usage during the exposure window. Look for unexpected API calls, resource creation, or data access.
4. Remove the key from the source. If it was committed to Git, rewrite the history using git filter-branch or BFG Repo-Cleaner. Simply deleting the file in a new commit is not sufficient — the key remains in history.
5. Implement prevention measures. Add pre-commit hooks, enable GitHub secret scanning push protection, and review your secrets management practices.

Prevention: Best Practices for API Key Security

Use Environment Variables

# .env file (NEVER commit this)
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxx
DATABASE_URL=postgres://user:pass@host:5432/db

# .gitignore (ALWAYS include this)
.env
.env.*
!.env.example

Use our ENV Validator to check your environment files for common issues and our .gitignore Generator to ensure your ignore rules are complete.

Use a Secrets Manager

For production workloads, move beyond .env files to a proper secrets manager:

• AWS Secrets Manager or SSM Parameter Store for AWS workloads
• HashiCorp Vault for multi-cloud environments
• Google Secret Manager for GCP workloads
• Azure Key Vault for Azure workloads

Scope Keys to Minimum Permissions

Apply the principle of least privilege to every API key. A key used only to read data should not have write permissions. A key used in a staging environment should not work in production. Most API providers support key scoping — use it.

Rotate Keys Regularly

Implement automatic key rotation with overlap periods. During rotation, both the old and new keys should work for a brief transition window. Automate this process so it happens without human intervention.

Never Put Keys in URLs

# BAD - key in URL (gets logged everywhere)
GET /api/data?api_key=sk_live_xxxx

# GOOD - key in header (not logged by default)
GET /api/data
Authorization: Bearer sk_live_xxxx
X-API-Key: sk_live_xxxx

Share Secrets Securely

When you need to share an API key with a teammate, never use email, Slack, or any persistent messaging platform. Use a tool with zero-knowledge encryption and auto-expiration. SecureBin's encrypted paste is designed for exactly this purpose — share a secret with a link that self-destructs after being read.

Frequently Asked Questions

How quickly do attackers find exposed API keys?

Research shows that exposed keys on public GitHub repositories are discovered and exploited within minutes. Automated scanners continuously monitor public commit feeds. In one study, AWS keys committed to a public repo were used to spin up EC2 instances within 4 minutes of the commit. This is why immediate revocation is essential — you cannot outpace automated scanners.

Is it safe to use API keys in frontend JavaScript?

Only if the key is specifically designed for client-side use and has appropriate restrictions. For example, Google Maps API keys can be restricted to specific domains and limited to specific APIs. Stripe publishable keys (pk_live_) are safe for frontend use. However, secret keys, database credentials, and service account tokens must never appear in client-side code. When in doubt, use a backend proxy to make API calls on behalf of the frontend.

I removed the key from my repo. Am I safe now?

No. Deleting a file in a new Git commit does not remove it from history. Anyone with access to the repository can view the old commit and extract the key. You need to rewrite Git history using tools like BFG Repo-Cleaner or git filter-repo. Even then, if the repository was ever public (even briefly), you must assume the key was compromised and rotate it.

How do I scan my entire organization for leaked keys?

Start with GitHub's organization-level secret scanning (available on GitHub Enterprise and public repos). For a broader scan, use TruffleHog or GitLeaks across all repositories. For web property scanning, use the SecureBin Exposure Checker to test your domains for exposed configuration files, debug endpoints, and other common leak vectors. Combine these with Google dorking for your domain name and known key prefixes.

The Bottom Line

API key exposure is one of the most common and most preventable security failures. The combination of automated scanning tools, proper secrets management, pre-commit hooks, and regular audits can reduce your risk dramatically. Do not wait for a breach notification from your cloud provider — proactively check your repositories, web properties, and public sources today.

Related tools: Exposure Checker, ENV Validator, Hash Generator, SSL Checker, .gitignore Generator, and 70+ more free tools.