An API key is a password, but for a piece of software instead of a person. When an app or a website needs to access another, like your accounting tool pulling in bank transactions or your website sending a booking confirmation by email, it has to prove it’s allowed to. That’s what an API key shows.
You don’t need to type it in every time, the way you would a login password. It gets stored once, inside the app or the script, and from then on it’s sent automatically with every request, behind the scenes, without you having to see it.
Why an API key only opens one door
Your building has a front-door key that opens everything: offices, server room, the lot. Nobody hands that one out. An API key is closer to the cleaner’s key: it opens the door it’s meant for, at the hours it’s meant for, and it’s traceable to whoever holds it.
Give it to the wrong person, and they don’t get the whole building. They get whatever’s behind that one door. However, if you don’t limit the access of the API key, then they will be able to access everything.
What does an API key actually look like?
A key is just a long, meaningless-looking string of letters and numbers. Software attaches it to every request it makes, so the receiving service can check it before doing anything.
That’s the whole mechanism. There’s no login screen, no second factor by default. Whoever has the string has the access it grants.
Why are API keys worth caring about?
If your API key gets leaked and ends up somewhere public, such as a shared script, a public code repository, or a screenshot in a support ticket, anyone who finds it can use it to get into your account exactly as if they were you, for as long as it takes someone to notice and revoke it. Automated scanners crawl public repositories specifically hunting for strings shaped like API keys, so a working key can be found and used long before anyone notices it has leaked.
How to keep your API keys secure
- Keep it out of your code. Never type an API key directly into a script; this is the single most common way one ends up on the internet. Keys should be stored as environment variables or in a secrets manager.
- Give it the smallest job possible. Always make sure the key can only access what it needs to: no more, no less. A narrowly scoped key limits the damage if it does leak.
- Refresh the key on a schedule, and whenever the people with access to it change. Treat an API key like a lock you occasionally re-key: change it routinely, and immediately when anyone who had access no longer should.
- Know where the switch is before you need it. If a key does get leaked, it’s better to already know how to shut it down so you can move as efficiently as possible. Every vendor has a button that revokes a key. Find it now, not while you’re mid-panic during an actual leak.
It’s not just API keys that get exposed
API keys are one small example of a much bigger habit: credentials that are easy to create and easy to forget about. Most businesses we work with are holding more of them, in more places, than anyone realised.
