Leaked API keys invite bots in through the side door
Where keys actually leak
The common sources are unglamorous: a key committed to a public code repository during a rushed fix, a key embedded in a mobile app where anyone who unpacks the file can read it, a key pasted into a support ticket or a screen recording. None of these need an attacker inside your systems. Search tooling indexes public repositories continuously, and a leaked key can be found within hours of posting.
Treat any key that has lived in a client side bundle as public by design. If the app ships to devices you do not control, the key ships with it. Client keys need narrow scopes and per app restrictions, or they are simply published credentials with extra steps.
Abuse through a key has a shape
Compare the key's traffic to its purpose. A key issued for a warehouse inventory sync that suddenly enumerates the full product catalogue, or calls from consumer ISP address ranges in several countries at once, is no longer doing its job. Scope is the detection: legitimate integrations are boringly repetitive, same endpoints, same hours, same source ranges.
Scraping through a leaked key is harder to spot than storefront scraping because the responses are clean JSON and the error rate is low. Watch volume per key against its own baseline, not against a global threshold. A key doing ten times its normal catalogue reads is a finding even if the total is small next to site traffic.
Rotate without breaking the integration
Issue the replacement key first, deploy it to the legitimate integration, watch the old key's traffic fall to the legitimate pattern or to zero, then revoke the old key. Revoking first and issuing second turns a security fix into an outage, and outages teach teams to delay the next rotation.
Keep an inventory: key, owner, purpose, scope, source ranges, and review date. Most stores discover during an incident that nobody knows how many keys exist. The inventory is dull work that pays off exactly once, on the worst day, when it pays for itself completely.
Read only where reading is the job. No write access where the integration never writes. No checkout or customer endpoints on a key built for catalogue sync. When a narrowly scoped key leaks, the blast radius is a data exposure you can describe precisely. When a broad key leaks, it is a weekend.
Scope every key like it will leak
Put expiry on keys by default and renew on a schedule, the way you would a certificate. A key that never expires will outlive the integration, the vendor, and the employee who created it, in that order.
Keep reading: Which headless browser signals still separate bots from real shoppers?, How do bots abuse GraphQL endpoints that REST rate limits never see?.
Frequently asked questions
How can I tell if an API key has leaked?
Look for the key calling from new source ranges or countries, hitting endpoints outside its purpose, or running far above its own volume baseline. A sudden catalogue enumeration from an integration key is the classic first sign.
How can I tell if an API key has leaked?
Yes, in practice. Anyone can download the app and extract embedded strings. Client side keys must be treated as publishable, given narrow scopes, and paired with app attestation or server side proxies for anything sensitive.
How can I tell if an API key has leaked?
Revoke it as soon as the legitimate integration runs on a replacement. If the key touches payment or customer data, revoke first and accept the outage. For low scope keys, the staged rotation avoids breaking a live sync.
How can I tell if an API key has leaked?
Global limits rarely help, because abuse can sit under them. Per key limits tied to the key's normal pattern, plus scope restrictions, are what make a leaked key a poor tool for scraping or checkout abuse.