Here is a question worth being uncomfortable about: if one of your API keys leaked right now, how would you find out?
Not "how would you rotate it" — that part is easy. How would you notice?
A stolen key does not look stolen. It authenticates correctly, because it is a valid key. It hits the same endpoints, because whoever took it wants the same functionality you built. It bills to the same account. Every row it writes to your usage log looks exactly like a row you wrote.
The only thing that differs is where it comes from. Someone else's server is not the one you deploy from.
Which means if you are not recording the caller's address alongside the usage, there is no evidence a theft ever happened. You find out from the bill, weeks later, and even then you cannot tell which calls were yours.
What makes this a nasty class of problem is that the fix is trivial and almost nobody does it until after the incident. One column. The hard part is the alerting: most legitimate integrations call from several addresses — a few app instances, a laptop, CI — so "more than one address" fires constantly and gets ignored, and then it is not there on the day it matters.
The heuristic I settled on: never flag the busiest source, and only flag a minority share once there is enough traffic for a share to mean anything. Quiet enough to still be believed.
What do you do — per-key IP allowlists, anomaly alerting, or nothing until something looks weird on the invoice?
Top comments (0)