Is a leaked cloud key sitting in our code actually a big deal?

The question

A developer had spotted the key during a routine review of the client's site — an old build artifact nobody remembered leaving there, still active.

What we told them

Not overreacting — under-reacting, if anything. A key sitting in client-side JavaScript isn't hidden. Anyone who opens the browser's developer tools or simply views page source can read it, same as any other visible text on the page. "Nobody would think to look" isn't a security control; automated scanners look for exactly this, constantly, across the entire web.

This month gave a concrete example of how fast it goes wrong. A CRM platform used by over a thousand organizations had an AWS access key exposed in a public JavaScript build file on its own website. From the moment attackers found it to the moment they had exfiltrated the platform's entire customer database — names, emails, phone numbers, donation records — took roughly ninety minutes. Not a sophisticated attack. Just a key that shouldn't have been visible, sitting somewhere it was.

We walked the client through three things:

• Rotate first, investigate second. The moment you find an exposed key, treat it as already compromised and revoke it. Deleting the file it was in does nothing — the key itself is still valid until you kill it.
• Check what the key could actually touch. A narrowly-scoped key that could only read one bucket is a bad day. A key with broad account access is the whole business. Scope is what decides whether an exposure is embarrassing or catastrophic.
• Scan your own public code on a schedule, not once. A one-time cleanup catches what's there today. New commits, new build artifacts, and new third-party scripts can reintroduce a secret next month — treat this like a recurring check, not a one-off fire drill.