Skip to content
Qubitron Security

3 min readQubitron Labs security team

Your frontend is leaking: source maps and API keys in shipped code

Apple's App Store website and Claude Code both shipped source maps. Researchers keep finding live keys in bundles. How to check your own app in an afternoon.

  • Source maps
  • Secrets
  • Web security

Everything your web app needs to run is sent to every visitor. Usually that's minified JavaScript, which an AI agent can read anyway. Sometimes it's much more: the original source, through a published source map, or a live credential sitting in the bundle. In the last year, both happened to some of the best-resourced engineering teams in the world.

Two source map leaks

  • Apple's App Store website. When Apple relaunched apps.apple.com in late 2025, the production site shipped JavaScript source maps, according to Escape's analysis. Someone archived the reconstructed front-end source on GitHub. Apple's DMCA notice, filed on 5 November 2025, covered its "copyrighted source code and assets" for the site, and GitHub took down 8,270 repositories.
  • Claude Code. On 31 March 2026, The Register reported that the official npm package for Anthropic's Claude Code included a map file pointing to an archive of about 1,900 TypeScript files and more than 512,000 lines of code. A security researcher spotted it. Anthropic said it was a packaging mistake caused by human error, and that no customer data or credentials were exposed.

Neither leaked customer data. Both handed out the one thing obfuscation and minification exist to protect: readable source, with names, comments and structure intact.

Keys in bundles, measured at scale

  • Researchers from Stanford, UC Davis and TU Delft analysed 10 million rendered websites and found 1,748 credentials for 14 providers, which often stayed exposed for months or years. Their key finding: "62% of JavaScript-based exposures manifest exclusively within compiled deployment bundles". Scanning your repository isn't enough; the secret often only appears after the build.
  • Intruder scanned JavaScript bundles from about 5 million applications and pulled out more than 42,000 tokens of 334 types, including 688 code-repository tokens, many still active.
  • Truffle Security found 11,908 live secrets in a December 2024 web crawl, noting developers had hardcoded them into HTML forms and JavaScript snippets instead of keeping them on the server.

When a harmless key stops being harmless

Google Maps and Firebase keys were long treated as safe to embed in a page. Then Gemini arrived. In February 2026, Truffle Security found 2,863 live Google API keys in a public web crawl that could authenticate to Gemini, because the Generative Language API had been enabled on the same project. Its summary: "Your public Maps key is now a Gemini credential." Google has since tightened this: from 19 June 2026, the Gemini API rejects requests from unrestricted standard API keys.

The lesson is general. A key's risk depends on what the project behind it can do today, not what it could do when you shipped it.

Check your own app this afternoon

Do this on your own production site:

  1. Look for source maps. Open your production bundle and check whether the last line has a sourceMappingURL comment, then try requesting the same file with .map appended. If either works for the public, your original source is public too.
  2. Search the built output, not just the repo. Run your secret scanner over the build directory your CI produces, and over what the browser actually downloads.
  3. Inventory every key in the client. For each one, ask what else is enabled on its project, and restrict it to the exact APIs and referrers it needs.
  4. Move anything paid or private behind your server. If a key can spend money or read data, the browser should never hold it. Proxy the call and rate-limit per user.
  5. Rotate after removal. A key deleted from today's bundle is still in yesterday's, in caches and in crawls.
  6. Read your own bundle like an attacker would. Internal routes, feature flags, pricing rules and debug endpoints are as revealing as keys.

Steps 1 to 5 take an afternoon. Step 6 is what our AI reverse-engineering exposure audit does properly: the same tooling an attacker would point at your build, with evidence for everything it recovers. If you'd like a quick first look, request a free exposure check.

Sources

Keep reading

All posts

Next step

Find out what your app gives away. Book a free exposure call.

Thirty minutes with an engineer, not a sales deck. Tell us what you ship; we tell you what we'd look at first and what an audit would involve.

Book a free exposure callRequest an audit

We only test applications you own or are explicitly authorized to test.