API keys in your code: why it matters and how to fix it
The short answer: An API key is a password for software. If one is written into your code, anyone who sees the code can use it as you. If you find one, change it (rotate it) first: deleting it from the code isn't enough, because copies live on in the history. Then move keys out of the code for good.
Software talks to other software all the time. Your website takes payments through Stripe, sends email through a mail service, stores files in the cloud and maybe uses an AI model. Each of those connections uses an API key: a long string that works like a password, proving to the other service that the request really comes from you.
Those keys have to live somewhere. Too often, they end up written straight into the code.
Why it matters
Whoever has the key can act as you. Depending on the key, that might mean:
- Reading or deleting your customers' data.
- Running up a huge bill on your cloud or AI account.
- Sending email or texts in your name.
- Taking payments, issuing refunds or reading transactions.
And code travels further than you'd think: to every developer who worked on it, every laptop it was copied to, code-hosting sites such as GitHub, and sometimes straight into the browser of everyone who visits your site.
This is not rare. GitGuardian, which scans public code for leaked secrets, found 29 million new ones on public GitHub in 2025 alone, up 34% on the year before. Worse, most leaked keys are never changed: 64% of the secrets it confirmed were valid in 2022 still worked four years later.
The first thing to do: change the key
If you find a key in your code, the first step is always to revoke or rotate it: cancel the old key and create a new one, in the service it belongs to (Stripe, AWS, your email provider and so on).
Deleting it from the code is not enough. Code-hosting tools keep a full history, so the old key is still there in earlier versions, and in every copy anyone has made. GitHub's own guidance says that if a secret has been committed, revoking or rotating it is the first step.
Then:
- Check whether it was used. Most services show recent activity or usage. Look for anything you don't recognise.
- Move the new key out of the code (see below).
- Clean up the history if the code is shared or public, so the old key stops turning up in searches. This is tidying up, not protection: the key you changed is what protects you.
How to find keys in your code
- Search for the obvious words:
key,secret,token,password,api. Crude, but it finds a surprising amount. - Use a scanner. Free, open-source tools such as gitleaks (MIT licence) and TruffleHog (AGPL licence) search your code and its whole history for things that look like keys. TruffleHog can also check whether a key still works.
- Let GitHub help. On public repositories, GitHub scans for known types of key for free and, by default, blocks you from pushing many of them by mistake. On private repositories this is a paid add-on.
- Check the browser too. For websites and apps, look at the code your visitors actually download. Some keys are designed to be public; anything marked "secret" or "server" must never be there.
Where keys should live instead
- Environment variables or a
.envfile on the server, which is never added to the code repository. The code reads the key when it runs. - A secrets manager for bigger setups, such as the one built into your cloud provider or your deployment tool.
- Only on the server. Anything secret stays on the server side. The browser only ever gets keys that are meant to be public.
And give each key only the access it needs. A key that can only send email does far less damage if it leaks than one that can do everything.
When to call someone
Call for help if:
- You find keys and aren't sure which services they belong to, or what they can do.
- A key has been public, or on a laptop or repository you no longer control.
- You see activity on an account that you can't explain.
- Changing a key would break things and you don't know what depends on it.
A server health check includes looking for secrets in your code and on your server, with a clear list of what to change first. If you think a key has already been used against you, go straight to breach help.
Sources
Want me to sort it for you?
One server reviewed, a plain-English report, prioritised fixes and a 30-minute call.