In this guide · 7 sections
Short answer
If a key leaked, revoke or rotate it first, then update your app and check usage and bills. Prevent repeats by keeping secret keys on the server, never in website or app code, turning on GitHub secret scanning and push protection, and setting spending limits on every paid API.
How API keys usually leak
Most leaks are accidents during building or testing, not hacks:
- Keys in website or app code. A developer puts an OpenAI or email-service key in JavaScript so the page can call the API directly. Anyone can open the browser's developer tools and read it. OpenAI's API key safety guide says never to deploy keys in browsers or mobile apps.
- Keys committed to Git. A config file or .env file pushed to GitHub, even briefly. Removing it in a later commit leaves it in the history.
- Keys pasted where they shouldn't be. Issues, pull request comments, wikis, chat messages, screenshots in support tickets.
- AI-built or no-code apps. Quick prototypes often call paid APIs straight from the browser. Our guide to vibe-coded apps and business risks covers this pattern.
Which keys are safe to be public, and which aren't
Not every key in your website's code is a leak. Some providers issue keys designed for the browser:
| Key type | Safe in website code? | What to do |
|---|---|---|
| Stripe publishable key (pk_) | Yes | Stripe says only publishable keys are safe outside your backend |
| Stripe secret (sk_) or restricted (rk_) key | No | Server only; Stripe recommends restricted keys over secret keys |
| Google Maps browser key | Yes, if restricted | Restrict to your website domains and only the APIs you use |
| OpenAI, Anthropic, Gemini API keys | No | Call them from your server or a backend function |
| Email, SMS and WhatsApp provider keys | No | Server only; these can send messages in your name |
| Database or cloud admin credentials | Never | Server only, ideally in a secrets manager |
Sources: Stripe's API keys documentation and Google Maps Platform security best practices, as of October 2026.
How to check whether your keys have leaked
Start with the places a key is most likely to be exposed:
Leaked key check
GitHub's secret scanning scans the entire Git history on all branches, plus issues, pull requests, discussions and wikis. It runs automatically for free on public repositories. For private repositories in an organisation, it needs GitHub Secret Protection on a Team or Enterprise plan. GitHub also works with service providers: when it finds a partner's key, it notifies that provider so they can act, such as revoking it.
What to do in the first hour after a leak
GitHub's own guidance is to rotate the affected credential immediately; cleaning Git history is slow and often unnecessary once the key is revoked.
Revoke or rotate the key
In the provider's dashboard, create a new key and delete or disable the leaked one.
Update your app with the new key
Store it in a server-side environment variable or secrets manager, not in code. Redeploy.
Check usage and bills
Look for activity you don't recognise from the time the key was exposed. Screenshot it for the provider and your records.
Contact the provider if you were billed for misuse
Explain the leak and what you've done. Whether they offer credits is their decision.
Check what the key could reach
If it gave access to customer data, such as a CRM, email or database key, assess whether this is a data breach under the PDPA.
Remove it from code and history
Delete it from the current code. Rewriting Git history is optional once the key is revoked, but stops it showing up in future scans.
Limit the damage next time
You can't guarantee a key never leaks, but you can make a leaked key cheap.
- Spending limits with hard enforcement. OpenAI's key safety guide recommends monthly spend limits for the organisation or projects with hard enforcement, noting that spend alerts alone don't stop traffic. Our guide to AI API cost control covers the settings for each vendor.
- One key per app and per person. OpenAI says sharing keys is against its terms; separate keys mean you can revoke one without breaking everything.
- Expiry dates and rotation. OpenAI project keys can be created with an expiry date, and admins can enforce a maximum key lifetime.
- Least privilege. Use Stripe restricted keys and API restrictions on Google keys so a leaked key can do as little as possible.
- Push protection. GitHub's push protection for users is on by default on GitHub.com and blocks secrets in pushes to public repositories. Repository-level push protection needs GitHub Secret Protection.
The OWASP Secrets Management Cheat Sheet is the standard reference for developers who want the full picture: secrets managers, rotation and detection.
Do it yourself or get help?
Rotating a key and setting a spending limit takes minutes and is worth doing today if you have any doubt. Moving API calls from the browser to a server, or auditing an app someone else built, needs a developer.
Our Website Security Hardening (S$290) updates core, themes and plugins, removes unused plugins and users, adds login protection with 2FA for admins, a web application firewall, security headers and an off-site backup. If keys need moving out of browser code into a small server-side function or proxy, our Custom Tool or Dashboard starts from S$1,990 with a free written scope.
Frequently asked questions
Revoke or rotate the key immediately in the provider's dashboard, then update your app with the new key stored outside the code. Check usage and billing for activity you don't recognise. Removing the file or making the repository private doesn't help on its own, because the key may already have been copied. Clean the Git history afterwards if you want.
Only if the provider designed that key to be public, such as a Stripe publishable key or a Google Maps key restricted to your domain. Secret keys for OpenAI, Stripe secret or restricted keys, email or SMS providers must stay on your server. Anyone can read browser code with developer tools, so a secret key there is effectively public.
On public repositories, yes. GitHub secret scanning runs automatically for free, covers the whole Git history and issues, pull requests and wikis, and notifies partner providers about their keys. For private organisation repositories it needs GitHub Secret Protection. Push protection for users, on by default, blocks secrets in pushes to public repositories.
Yes. A leaked key gives access to your account quota, which can mean unexpected charges and interrupted service. OpenAI recommends monthly spend limits with hard enforcement, because alerts alone don't stop traffic, plus key expiry dates, one key per person or app, and never putting keys in browser or mobile app code.
Not urgently, once the key is revoked. GitHub's documentation says removing secrets from history is time-consuming and often unnecessary after the credential has been revoked. The priority is rotating the key. Rewriting history is still worth doing in time so the old key stops appearing in scans and nobody mistakes it for a live one.