Log a key identifier, never the key itself, on every API call along with source, endpoint, status and volume. Build a simple baseline for each key, then alert on use from a new network, endpoints the key never touched, sudden bursts and repeated authentication errors.
Why keys need watching
An API key is a long lived password for a program. It gets pasted into scripts, committed to repositories and left in logs. The OWASP REST Security Cheat Sheet says keys issued to third parties are relatively easy to compromise, and that they should not be the only protection for sensitive or high value resources. It advises revoking a key if the client breaks the usage agreement.
When a key leaks, the first sign is often odd traffic, not an alert from the key holder.
What to log per request
- Key ID or client ID, a stable label that is not the secret.
- Tenant that owns the key.
- Verified source IP. See which client IP to log behind a proxy.
- Method and route template, not the raw URL.
- Status code and response size.
- Duration and request ID.
The REST cheat sheet is firm on one point: passwords, tokens and API keys should not appear in the URL, since they can be captured in web server logs. Accept keys in headers, and strip the header from logs. It also advises logging token validation errors to detect attacks and sanitising log data to prevent log injection.
Baseline per key
For two weeks, compute for each key its usual source networks, endpoints, call rate by hour and error rate. Store the summary, not every event, so it stays cheap.
Detections to build
| Signal | Example condition | What it may mean |
|---|---|---|
| New source | Key seen from an address block it never used | Leaked key or moved workload |
| New endpoints | Key touches routes outside its usual set | Reconnaissance with a stolen key |
| Burst | Rate far above hourly norm | Scraping or data pull |
| Auth errors | Many failures then a success | Key guessing |
| Dormant key wakes | No use for months, then activity | Old key found in an archive |
| Many 429 responses | Repeated rate limit hits | Abuse or a broken client |
The REST cheat sheet says to return 429 Too Many Requests when requests arrive too quickly, so a run of 429 responses is both control output and a signal.
Response plan
- Contact the key owner and confirm whether the activity is expected.
- If not, revoke the key and issue a new one through a separate channel.
- Review what the key accessed during the suspicious window.
- Search your own code and logs for the exposed key to find the leak.
- Add scoping, expiry and per key limits so the next leak has less reach.
Scoped, short lived keys help most. They make misuse both rarer and easier to spot.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is it safe to log the first few characters of a key?
A short prefix is a common way to identify a key. Prefer a separate key ID, and keep any prefix too short to help guessing.
What if the traffic is a customer's new server?
Confirm with them. Letting customers register expected networks reduces these false alarms.
Safeguard includes API security scanning in its scan set, alongside dependency and code analysis. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
