API Key Exposure: What It Is, How It Happens, and How to Fix It

What is an API key?

An API key is a secret credential — a long string of characters — that authorises your application to use a third-party service. When your website calls Stripe to process a payment, it sends an API key to prove it is authorised. When your app sends an email via SendGrid, it authenticates with an API key. When your code reads from an AWS S3 bucket, it uses an AWS access key.

API keys are essentially passwords for your software. If someone else gets hold of one, they can use the service as if they were you — running up bills, accessing data, sending emails, or in the worst cases, deleting everything.

How API keys get exposed

The most common cause is accidental commits to version control. A developer adds a configuration file with a real API key in it, forgets it is there, and pushes it to GitHub. If the repository is public — or becomes public later — the key is now visible to anyone in the world.

GitHub has automated scanning that looks for this, but by the time it flags an issue, automated bots may have already harvested the key. Research consistently shows that exposed secrets are typically discovered and abused within minutes of being pushed.

Other common exposure routes:

• Public GitHub repositories — the most common. Old projects, portfolio repos, or open-sourced internal tools with credentials left in config files
• .env files committed by mistake — .env should always be in .gitignore, but it frequently is not
• Hardcoded keys in frontend code — API keys embedded in JavaScript that ships to the browser are readable by anyone who views the page source
• Publicly accessible config files — config.js, settings.json, or similar files served directly from a web server
• Old repositories not cleaned up — a key rotated six months ago might still be sitting in git history, accessible via git log

What attackers do with exposed keys

The consequences depend on what service the key controls.

AWS keys are among the most dangerous. An attacker with your AWS access key can spin up hundreds of GPU instances for cryptocurrency mining, exfiltrate your entire S3 storage, or delete your infrastructure — all billed to your account. AWS bills of £20,000–£50,000 from a single compromised key are not unusual.

Stripe keys allow an attacker to issue refunds, create charges, access customer payment data, or transfer funds depending on the key's permissions.

SendGrid or Mailgun keys are used to send spam or phishing emails at massive scale — your domain's reputation takes the hit.

GitHub tokens with write access allow an attacker to modify your codebase, introduce backdoors, or wipe repositories.

Database connection strings give direct access to your data.

How to find out if your keys are exposed

Scan your domain and GitHub repos with Olimpio

Olimpio's Secrets feature scans your connected GitHub repositories and your domain for exposed API keys and credentials. It checks for patterns matching AWS keys, Stripe keys, Twilio, SendGrid, and dozens of other services — and flags anything it finds with the file location and a masked version of the value.

Connect your GitHub account and run a secrets scan to check your repositories automatically.

Search GitHub manually

You can search GitHub's code search for your own domain name or organisation name to see if any repositories — including forks or archived projects — contain references to your credentials:

site:github.com "yourdomain.com" "api_key"

Also check for your company name combined with common credential patterns.

Check your git history

Even if you have removed a key from your current codebase, it may still exist in your git history. Run:

git log -p | grep -i "api_key\|secret\|password\|token"

If you find a key in history, removing it from the current commit is not enough — you need to rewrite git history using a tool like git filter-repo, or treat the key as compromised and rotate it immediately.

What to do if you find an exposed key

1. Revoke it immediately. Do not wait. Go to the service's dashboard and invalidate the key right now. A key that no longer works cannot be abused further.

2. Generate a new key. Create a replacement with the minimum permissions needed for the task. Do not reuse the old key value.

3. Check for abuse. Look at the service's usage logs for any activity you do not recognise — unexpected API calls, unusual access patterns, charges you did not initiate.

4. Remove it from the codebase and history. Delete the exposed file or value from your code, update .gitignore to prevent it happening again, and clean git history if the key was committed.

5. Move credentials to environment variables. API keys should never be hardcoded. Use environment variables (.env files locally, proper secrets management in production) so credentials are never in the codebase at all.

Preventing it in future

A few habits that eliminate most API key exposure risk:

• Always add .env to .gitignore before your first commit. Not after.
• Use secret scanning tools. GitHub has built-in secret scanning for public repos. Enable it, and consider a pre-commit hook like git-secrets that blocks commits containing credential patterns.
• Apply the principle of least privilege. Every API key should have only the permissions it actually needs. A key that reads from S3 should not also have permission to delete buckets.
• Rotate keys regularly. Olimpio's key rotation tracker lets you set rotation intervals and get reminder emails when keys are due — so rotation becomes a habit rather than an afterthought.
• Audit old repositories. Go through old GitHub projects and either archive them with secrets removed, or make sure .gitignore was set up correctly from the start.

API key exposure and Cyber Essentials

Exposed credentials are a direct failure of Cyber Essentials Control 3 (Access Control). The principle that only authorised users should have access to your systems extends to API credentials — a leaked key is an open door.

Run a free secrets scan with Olimpio to check your repositories and domain for exposed credentials before an attacker finds them first.