How to Check if API Key is Exposed (Step by Step)

API keys are the silent gatekeepers of your infrastructure. When one leaks, attackers can access your databases, drain your cloud budget, and exfiltrate customer data in minutes. This guide walks you through every method to check if your API keys are exposed, covering AWS, Stripe, Google, and other common providers.

Why Exposed API Keys Are a Critical Threat

According to GitGuardian's 2025 State of Secrets Sprawl report, over 12.8 million new secrets were detected in public GitHub commits in a single year. That number continues to grow. Each exposed key represents a potential entry point into production systems, billing accounts, and customer databases.

The damage from a leaked API key can be immediate and severe. In 2024, a developer accidentally pushed an AWS access key to a public repository. Within four minutes, automated bots had discovered the key and spun up cryptocurrency mining instances. The resulting bill exceeded $45,000 before the key was revoked. This is not an isolated case. Attackers run continuous scans against GitHub, GitLab, Bitbucket, and other code hosting platforms, searching for exactly these kinds of mistakes.

The problem is not limited to code repositories. API keys leak through client-side JavaScript, mobile app binaries, Docker images, CI/CD logs, Slack messages, and even Stack Overflow posts. If you have ever used an API key in any project, there is a real chance it has been exposed somewhere.

Types of API Keys and Their Risk Levels

AWS Access Keys (AKIA...)

AWS access keys consist of an Access Key ID (starting with AKIA) and a Secret Access Key. These are among the most dangerous keys to expose because they can grant full programmatic access to your AWS account. An attacker with a valid AWS key pair can launch EC2 instances, access S3 buckets, read RDS databases, and modify IAM policies. AWS actively scans GitHub for leaked keys and will send you a notification, but by the time you receive it, the damage may already be done.

Stripe API Keys (sk_live_...)

Stripe secret keys begin with sk_live_ for production and sk_test_ for test environments. A leaked live secret key gives an attacker the ability to issue refunds, create charges, access customer payment information, and modify your account settings. Stripe has built-in leak detection with GitHub, but relying solely on their detection leaves a window of vulnerability.

Google Cloud API Keys

Google Cloud API keys can be restricted to specific APIs and IP addresses, but many developers leave them unrestricted. An exposed unrestricted Google API key can be used to rack up charges on Maps API, Places API, Translate API, and dozens of other billable services. Google provides alerts through their Secret Manager integration, but keys embedded in frontend JavaScript are especially common and often overlooked.

Database Connection Strings

Connection strings containing credentials for PostgreSQL, MySQL, MongoDB, and Redis are frequently found in exposed .env files and configuration files. These provide direct database access, which is typically the most damaging type of credential exposure. For more on this, read our guide on exposed .env files.

Other High-Risk Keys

• SendGrid / Mailgun API keys allow sending email from your domain (phishing attacks)
• Twilio keys enable sending SMS and making calls on your account
• GitHub Personal Access Tokens can access private repositories and organization data
• Slack webhook URLs allow posting messages to your channels
• Firebase keys can expose user authentication data and Firestore databases
• OpenAI / Anthropic API keys can consume expensive AI compute credits

Method 1: Search GitHub for Your Keys

GitHub is the most common place where API keys are accidentally exposed. Even if you have deleted a commit containing a key, the data often persists in git history. Here is how to search effectively.

Using GitHub Code Search

Go to github.com/search and use these search operators to find potential leaks:

# Search for a specific key prefix in your org
org:your-org-name AKIA
org:your-org-name sk_live_
org:your-org-name password

# Search for common secret patterns
"AKIA" language:python
"sk_live_" language:javascript
"mongodb+srv://" language:env

# Search for your domain in connection strings
"your-company.com" password
"your-rds-endpoint" filename:.env

Be thorough. Search for partial key values, your company name combined with credential keywords, and common configuration file names like .env, config.yml, secrets.json, and application.properties.

Using GitHub Secret Scanning

If you have GitHub Advanced Security (included free for public repositories), enable secret scanning in your repository settings. GitHub automatically detects over 200 secret patterns from 100+ service providers and will alert you when a known secret format is detected in your code. For organizations, enable push protection to block commits containing secrets before they reach the repository. Learn more about detecting secrets in our dedicated guide on detecting secrets in GitHub repositories.

Method 2: Google Dorking for Leaked Keys

Google indexes more than you might expect. Pastebin posts, public Trello boards, Jupyter notebooks, and misconfigured web servers all get crawled and indexed. Use these search queries to find your exposed keys:

# Search for your keys on paste sites
site:pastebin.com "your-api-key-prefix"
site:gist.github.com "your-company-name" password

# Search for exposed config files
site:your-domain.com filetype:env
site:your-domain.com filetype:yml password
intitle:"index of" ".env" "your-domain"

# Search for keys in public documents
"your-aws-account-id" filetype:json
"your-s3-bucket-name" password OR secret OR key

Run these searches regularly. New leaks can appear at any time as previously private repositories are made public, employees share code snippets, or web server configurations change.

Method 3: Use Automated Scanning Tools

SecureBin Exposure Checker

The SecureBin Exposure Checker scans your domain for exposed sensitive files, including .env files, .git directories, backup files, and configuration files that commonly contain API keys. It runs 19 parallel checks and delivers results in seconds. This is the fastest way to check if your web-facing infrastructure is leaking credentials.

TruffleHog

TruffleHog scans git repositories for high-entropy strings and known secret patterns. It examines the entire commit history, not just the current state of the code:

# Scan a GitHub repository
trufflehog github --repo=https://github.com/your-org/your-repo

# Scan a local git repository
trufflehog filesystem --directory=/path/to/repo

# Scan an entire GitHub organization
trufflehog github --org=your-org-name

Gitleaks

Gitleaks is a fast, lightweight secret scanner that works well in CI/CD pipelines:

# Scan a repository
gitleaks detect --source=/path/to/repo --verbose

# Scan only new commits (for CI/CD)
gitleaks detect --source=. --log-opts="HEAD~1..HEAD"

# Use a custom configuration
gitleaks detect --config=.gitleaks.toml

git-secrets (AWS)

AWS provides git-secrets specifically for preventing AWS credential leaks:

# Install and configure
git secrets --install
git secrets --register-aws

# Scan repository history
git secrets --scan-history

Method 4: Check Your Web Server Directly

Many API keys leak through web server misconfigurations. Check these common paths on your own servers:

# Check for exposed .env files
curl -s https://your-domain.com/.env
curl -s https://your-domain.com/.env.production
curl -s https://your-domain.com/.env.local

# Check for exposed git directory
curl -s https://your-domain.com/.git/config
curl -s https://your-domain.com/.git/HEAD

# Check for backup files
curl -s https://your-domain.com/config.php.bak
curl -s https://your-domain.com/wp-config.php.old
curl -s https://your-domain.com/application.yml.bak

# Check for exposed debug/info endpoints
curl -s https://your-domain.com/phpinfo.php
curl -s https://your-domain.com/debug
curl -s https://your-domain.com/actuator/env

Or save yourself time and let the SecureBin Exposure Checker run all of these checks automatically.

Method 5: Monitor Cloud Provider Alerts

Most major cloud providers now offer some form of credential exposure detection:

• AWS scans public GitHub repositories and sends alerts through AWS Health Dashboard. Enable AWS CloudTrail to detect unauthorized API calls using potentially leaked keys.
• Google Cloud offers Security Command Center with credential exposure findings. Enable organization-level scanning for comprehensive coverage.
• Stripe partners with GitHub for automatic secret scanning and will notify you via email and dashboard alerts.
• Azure provides Microsoft Defender for Cloud with secret scanning capabilities across Azure DevOps and GitHub.

What to Do When You Find an Exposed Key

If you discover that an API key has been exposed, follow this remediation checklist immediately:

1. Revoke the key immediately. Do not wait. Go to the provider's console and disable or delete the compromised key. Every second counts.
2. Generate a new key. Create a replacement key and update your application configuration.
3. Audit access logs. Check CloudTrail (AWS), Audit Logs (Google Cloud), or the provider's activity dashboard for any unauthorized usage during the exposure window.
4. Remove the key from source code. Delete the key from your repository. If it was committed to git, you need to rewrite history using git filter-branch or BFG Repo-Cleaner. Simply deleting the file in a new commit does not remove it from history.
5. Check for lateral movement. If the exposed key had broad permissions, check whether the attacker used it to create new credentials, modify IAM policies, or access other services.
6. Implement prevention measures. Set up pre-commit hooks, enable GitHub secret scanning push protection, and move secrets to a proper secrets manager. Read our guide on securing environment variables in production for best practices.

Code Example: Revoking and Rotating AWS Keys

# List current access keys
aws iam list-access-keys --user-name your-user

# Create a new access key
aws iam create-access-key --user-name your-user

# Update your application with the new key, then deactivate the old one
aws iam update-access-key --user-name your-user \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

# After confirming everything works, delete the old key
aws iam delete-access-key --user-name your-user \
  --access-key-id AKIAIOSFODNN7EXAMPLE

Preventing Future API Key Exposure

Detection is necessary, but prevention is better. Implement these controls to stop keys from leaking in the first place:

• Use a secrets manager. Store keys in AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, or Azure Key Vault. Never hardcode keys in source code. See our guide on securing API keys in code.
• Set up pre-commit hooks. Use tools like git-secrets, Gitleaks, or detect-secrets as pre-commit hooks to catch secrets before they are committed.
• Restrict key permissions. Apply the principle of least privilege. AWS keys should have minimal IAM policies. Stripe keys should be restricted to specific API versions. Google keys should be restricted to specific APIs and referrers.
• Rotate keys regularly. Set up automated key rotation. AWS Secrets Manager supports automatic rotation with Lambda functions. Many other providers offer similar capabilities.
• Use short-lived credentials. Prefer IAM roles with temporary credentials (STS AssumeRole) over long-lived access keys. Use OIDC federation for CI/CD instead of storing static keys in pipeline variables.
• Add .env to .gitignore. This should be the first line in every .gitignore file. Also add *.pem, *.key, and other sensitive file extensions.

Frequently Asked Questions

How quickly do attackers find exposed API keys?

Research from North Carolina State University found that exposed secrets on GitHub are discovered by automated bots within one to five minutes of being pushed. Some researchers have observed scanning activity beginning within seconds. This means that even if you immediately realize you pushed a key and delete the commit, it may already be too late. Always assume an exposed key has been compromised and rotate it immediately.

Is it enough to delete the commit containing the key?

No. Deleting a file or reverting a commit in git does not remove the data from repository history. The secret remains accessible through the git reflog and can be recovered by anyone who cloned the repository before the deletion. You must rewrite git history using tools like BFG Repo-Cleaner or git filter-repo to truly remove the secret. Even then, anyone who previously cloned or forked the repository still has the old history.

Can I use the same API key for development and production?

Never. Using the same key across environments dramatically increases the risk and blast radius of exposure. Development environments are typically less secure, with more people having access and fewer controls in place. If a shared key leaks from development, production is immediately compromised. Always use separate keys for each environment, and ensure production keys have the most restrictive permissions possible.

How do I check if someone has already used my exposed key?

Check the provider's access logs and activity dashboard. For AWS, review CloudTrail events filtered by the compromised access key ID. For Stripe, check the Dashboard Events log. For Google Cloud, review Cloud Audit Logs. Look for API calls from unfamiliar IP addresses, requests at unusual times, and actions you did not perform. If you find unauthorized activity, treat it as a security incident and follow your incident response procedures.

The Bottom Line

API key exposure is one of the most common and preventable security failures. The tools and techniques in this guide give you a comprehensive approach to detection. Start with an automated scan of your domain using the SecureBin Exposure Checker, then work through GitHub searches, Google dorking, and repository scanning tools. Most importantly, implement prevention measures so that keys never leak in the first place. The cost of a proactive security scan is nothing compared to the cost of a breached API key.

Related reading: How to Detect Secrets in GitHub Repositories, How Hackers Find Exposed API Keys, Exposed .env Files: The #1 Secret Leak, Secure Environment Variables in Production.