What an API key actually is
An API key is a long string that identifies you to a service and, in most cases, grants permission to use it. Weather data, maps, cloud storage, messaging, speech recognition and many other services hand out keys. If you want to know how programs use them, web APIs work by one program sending requests to another, and the key tells the service whose request it is.
The important property is that a key usually works for whoever holds it. The service cannot tell whether a request came from you or from someone who copied the string. Treat a key like a password, with one difference: it is often pasted straight into code, which is where the trouble starts.
How leaks happen
Most leaks are accidents, not break-ins. Typical routes include:
- Writing the key directly into a source file and committing it.
- Committing a configuration file that contains the key, such as a file with Wi-Fi details and tokens for an ESP-style project.
- Posting a code snippet, screenshot or forum question with the key still visible.
- Removing the key in a later commit while it remains in the repository’s history, which anyone can read.
- Bundling a key into a mobile app or web page, where users can extract it.
Making a repository private later does not undo the damage if the key was ever public, because copies may already exist.
How leaked keys are found and abused
Public code hosting sites are searched constantly, both by security researchers and by people with bad intentions. Automated tools look for strings that match the known shape of keys from popular services, and they work quickly, often within minutes of a push. Some services and hosting platforms also scan for their own key formats and may warn you or disable the key, but that is a safety net, not something to rely on.
What happens next depends on what the key can do. Possibilities include:
- Running up charges on a paid service in your name, for example by using cloud computing time or sending messages.
- Reading or deleting data the key has access to.
- Sending spam or abusive messages through a messaging account.
- Using your quota until your own project stops working.
A key with narrow permissions causes less harm than one with broad control. This is one reason to follow the principle of least privilege: give each key only the access it needs.
Safer ways to store secrets
The aim is to keep secrets out of the code and out of anything you share.
Environment variables. The program reads the key from the environment of the machine it runs on, so the source contains only the variable’s name. This is a common and simple approach on computers and servers.
A separate configuration file that is not committed. Keep keys in a local file and list it in your repository’s ignore file so version control never tracks it. It helps to commit an example file with dummy values so others know what to fill in. Check that the ignore rule is in place before the first commit, since ignoring a file after it has been committed does not remove it from history.
A secrets manager or the platform’s own secret storage. Hosting and automation services typically provide a place to store secrets and inject them when a job runs. This keeps them out of your repository altogether.
Hardware or device-level storage. On a microcontroller, keys often end up in flash alongside the program. Some chips can protect stored keys, but features differ, so consult the documentation for your specific part. At a minimum, avoid putting the same key in every device you build, so one stolen unit does not expose all of them.
A proxy you control. If a public web page or app needs a service, send requests through a small server of your own that holds the key, instead of embedding it in the client.
Also consider whether the key is needed at all. Some services offer limited keys that only allow reading, or that are restricted to certain addresses or apps. Use those where you can.
If a key has already leaked
Act in this order:
- Revoke or rotate the key in the service’s dashboard. This is the step that actually stops misuse. Deleting the commit does not.
- Create a replacement and place it in the safer storage described above.
- Check the usage logs and billing for activity you did not expect.
- Clean the history if you wish, using tools designed for rewriting repository history, but treat it as tidying. The old key must be considered compromised regardless.
- Tell collaborators if the key was shared with others.
If the leaked item is a password for a third-party account, change it and turn on two-factor authentication.
Habits that prevent repeats
Develop a routine before each push: look at what is about to be committed and check for anything that looks like a key or password. Many developers use a pre-commit check or a scanning tool to catch strings of that shape; these are useful but not perfect, so do not treat them as the only defence. Good coding habits, such as keeping configuration separate from logic, make leaks less likely in the first place.
Be careful with logs, error messages and screenshots, too. A debug print that includes a request header can expose a key as easily as source code can. Smaller, short-lived credentials, rotated now and then, limit how long any one mistake matters. No habit removes the risk entirely, but they reduce both the chance of a leak and its cost.