Integrations
Access keys: how not to get it wrong
One per integration, out of the code, and rotated before you have to.
An access key is a password no human types, and that is why it gets treated worse: it ends up in a repository, in a team chat, or in a script somebody copied. Three rules avoid nearly everything.
One per integration
If the ERP and the time-tracking system share a key, revoking it because one was compromised takes down the other. With one each, you revoke what is affected and move on.
Out of the code
In your system's environment variables, not in a file that gets committed. It is the commonest mistake and the worst to fix afterwards: deleting it from the code does not delete it from the history.
If it has leaked
- 1
Revoke it now
Before investigating how it happened. A leaked key stops working the moment it is revoked.
- 2
Create a new one and swap it
In the system that was using it.
- 3
Check what was done with it
Accesses are logged. That is where you see whether anyone used it.
Important
Changing the key in the code without revoking the old one fixes nothing: the old one still works for whoever holds it. Revoking is the step that counts.
Worth knowing
Rotating periodically even when nothing has happened turns rotation into a familiar chore rather than an emergency on the day it matters.
›Do they expire on their own?
They can be given an expiry, and it is a good idea.
›Can I see a key after creating it?
No. It is shown once; if lost, create another.
›How many can I have?
As many as you need. Many narrow keys beat one with every permission.
A real case
The situation
A developer finds a key was left in a public repository two weeks ago.
What you do
- Revokes it immediately
- Creates a new one and puts it in environment variables
- Reviews the access log for those two weeks
What you get
Confirms it was never used from outside and the incident closes in twenty minutes.
The situation
The API key is shared over messaging between three people and ends up on a supplier's phone.
What you do
- Creates one key per integration, not per person
- Revokes the one that circulated and issues a new one
What you get
Each connection has its own key, and revoking it breaks nothing else.
The situation
The key is hard-coded by somebody who no longer works there.
What you do
- Stores keys in the secret manager, not in code
- Rotates the key when the person leaves
What you get
A developer leaving stops being a security incident.
The situation
A key grants access to everything when the integration reads two fields.
What you do
- Gives each key the minimum scope it needs
What you get
A leaked key exposes two fields rather than the whole archive.
The situation
Nobody knows which keys are active or what for.
What you do
- Checks the list and notes what each one is for
What you get
The unused ones can be withdrawn.
The situation
A key has not been rotated in three years.
What you do
- Sets a rotation schedule with advance warning
What you get
Rotation happens calmly rather than after a scare.
This article answers
- create an api key
- i pushed a key to github what now
- rotate integration credentials
- revoke an api key