That API Key in Your Frontend? Attackers Found It Before Your Code Review Did

Cyble Research and Intelligence Labs recently found over 5,000 public GitHub repositories and approximately 3,000 live production websites leaking API keys through hardcoded source code and client-side JavaScript. Attackers are harvesting exposed credentials within five minutes of them hitting a public repo. Your frontend is not a safe place for secrets — and the "vibe coding" era is making this problem exponentially worse.

There is a specific kind of developer who reads about API key leaks and thinks "that won't happen to me." That developer has a .env file sitting in a public repo right now. Or they've hardcoded a Stripe key into a React component. Or they shipped a mobile app with an AWS access key embedded in the binary. The security industry has been screaming about this for years, and the problem is still getting worse — not better — because the speed of modern development has outpaced the security culture needed to support it.

The Scale of the Problem: 13 Million Secrets and Counting

GitGuardian's annual State of Secrets Sprawl report found approximately 13 million secrets sitting in public GitHub repositories. These aren't test keys or dummy values. They're live AWS IAM credentials, Stripe API keys, OpenAI tokens, database passwords, and OAuth secrets — all accessible to anyone with a browser. Threat actors are not passively waiting for these secrets to appear. Automated bots continuously scan public repositories, forks, gists, and even exposed JavaScript bundles on production websites. Research has shown that IAM credentials exposed on GitHub are typically harvested by attackers within five minutes of the commit.

The financial impact is real. The average cost of a data breach reached $4.88 million in 2024 according to IBM's annual report, a 10% increase from the prior year, and a significant percentage of those breaches trace back to exposed credentials. A single leaked Stripe key was found by Escape.tech researchers to have potential exposure worth $17 million in unauthorized transactions.

How API Keys Leak: The Five Most Common Paths

Understanding how secrets end up exposed is the first step to preventing it. These are the five paths that account for the vast majority of credential leaks:

1. Hardcoded in Source Code and Pushed to Git

The classic. A developer drops an API key directly into source code for testing, forgets to remove it, and pushes to a public repository. The .gitignore file wasn't updated, or the .env file was committed before the ignore rule was added. It happens constantly — GitGuardian detected millions of new occurrences in 2024 alone.

2. Embedded in Frontend JavaScript

Any API key embedded in client-side code — whether in a React app, a vanilla JavaScript file, or a bundled SPA — is public by definition. Browser developer tools make extraction trivial. Cyble's research identified approximately 3,000 production websites directly invoking APIs like OpenAI's ChatGPT from the browser, bypassing backend mediation entirely. These keys are not just visible; they're actively used in real time, making them immediately exploitable.

3. Exposed Configuration Files

In late 2024, security researchers found that 30,000 Postman workspaces had been exposed, containing live API keys, access tokens, and sensitive payloads including healthcare records and enterprise credentials. Postman is an API development tool, not a secret manager — but developers were using it to store real production tokens in publicly shared workspaces. Environment files (.env, config.json, settings.py, .aws/credentials) are other common culprits.

4. Leaked Through CI/CD Pipelines

CI/CD systems process secrets during builds and deployments. If those secrets are logged, cached, or stored in pipeline artifacts, they become permanently accessible in CI/CD histories. The GhostAction campaign, discovered in 2025, compromised CI workflows and harvested over 3,000 secrets across multiple organizations by exploiting this exact attack surface.

5. Baked Into Mobile App Binaries

API keys compiled into iOS or Android app binaries are extractable with basic reverse engineering tools. If your mobile app communicates directly with a third-party API using a hardcoded key, that key is public. Every user who downloads your app has it.

What Happens When a Key Gets Found

The consequences scale with the permissions attached to the leaked credential. At minimum, attackers can impersonate your application, consume API quotas, and generate massive bills. A leaked AWS IAM key with broad permissions can cascade into full infrastructure compromise — the attacker can spin up compute resources for cryptomining, access S3 buckets containing customer data, or pivot laterally through your cloud environment.

For AI API keys specifically, the risks include unauthorized generation of phishing content, scam scripts, and automated social engineering at scale — all billed to your account. Because AI API activity is often not integrated into centralized logging or SIEM systems, malicious usage can persist undetected until organizations encounter billing spikes or quota exhaustion.

Real-World Breaches: From DOGE to Capital One

On July 13, 2025, a private API key for xAI's language models was accidentally published on GitHub by a developer at the Department of Government Efficiency (DOGE). The key, embedded in a script called agent.py, granted access to more than 50 xAI language models. The exposure wasn't detected internally — it was flagged by GitGuardian. Security researchers warned that the key could be used without authentication to send requests and retrieve data from xAI systems, and the key remained live even after public disclosure. KrebsOnSecurity had previously reported another DOGE employee leaking similar API keys on GitHub, exposing models trained with sensitive government data.

The Capital One breach of 2019 remains the defining case study. An SSRF vulnerability combined with overly permissive IAM roles allowed an attacker to access cloud metadata services, retrieve temporary credentials, and exfiltrate data on over 100 million customers. The breach cost Capital One over $190 million in settlements and penalties. The root cause wasn't exotic — it was a credential with too much access and insufficient monitoring.

The Vibe Coding Problem

The rise of AI-assisted development — what the industry has started calling "vibe coding" — is accelerating the secret sprawl crisis. Developers and startups are prioritizing speed, experimentation, and feature delivery over security fundamentals. AI coding assistants generate functional code quickly, but they routinely hardcode API keys, skip backend proxy patterns, and produce configurations that expose secrets by default. When the developer doesn't know enough to catch these mistakes, and the code ships to production, you get exactly the situation Cyble's research describes: thousands of live websites with API keys sitting in their client-side JavaScript.

This isn't a theoretical concern. In Q1 2025, a major security provider revealed that 99% of surveyed organizations experienced at least one API security issue over the prior 12 months. The speed of modern development demands equally fast security tooling — and most organizations haven't caught up.

How to Actually Secure Your API Keys

1. Never put secrets in client-side code. Period. If your frontend needs to call a third-party API, route it through your backend. Your server makes the API call with the secret, and your frontend only talks to your server. This is not optional.
2. Use a secrets manager. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager. Store secrets centrally, rotate them automatically, and never let them touch source code.
3. Implement pre-commit scanning. Tools like GitGuardian, TruffleHog, and Gitleaks can catch secrets before they ever reach a repository. Embed them in your pre-commit hooks and CI/CD pipelines.
4. Enforce .gitignore discipline. Every project should ignore .env, credential files, and configuration files containing secrets from the very first commit. Template .gitignore files for your stack should be part of your project bootstrapping process.
5. Scope API keys with least privilege. Never issue keys with wildcard permissions. Restrict by IP, domain, or service. Set rate limits. If a key only needs read access to one bucket, don't give it write access to the whole account.
6. Rotate keys on a schedule. Treat API keys like passwords. Rotate them regularly, and rotate them immediately if there's any suspicion of exposure.
7. Monitor API usage for anomalies. Integrate API activity into your SIEM. Set alerts for unusual request volumes, requests from unexpected geographies, or API calls at unusual hours.
8. Scan your Git history. Don't just scan the latest commit. Use tools that traverse the entire commit history, including deleted branches and archived projects, to find historical exposures.

Key Takeaways

1. The scale is staggering: Approximately 13 million secrets sit in public GitHub repos. Over 3,000 production websites are actively leaking API keys through client-side code. Automated bots harvest exposed credentials within minutes.
2. Frontend code is public code: Anything in your JavaScript, mobile app binary, or client-side bundle is readable by anyone. There is no way to hide a secret in client-side code. Route API calls through your backend.
3. Vibe coding is making it worse: AI-assisted development accelerates feature delivery but also accelerates security mistakes. Code review and automated scanning must keep pace with development speed.
4. Git history is forever: Deleting a secret from current code does not delete it from Git history. Once committed, the credential must be revoked and rotated — there is no other fix.
5. Treat API keys as critical secrets: They are authentication credentials with direct access to your infrastructure, data, and billing. Manage them with the same rigor you'd apply to admin passwords.

The API key problem is not a technology problem. It's a culture problem. Development teams that treat secrets as an afterthought will continue to be the organizations featured in breach disclosures. The tools to prevent credential leaks exist. The question is whether your team uses them before an attacker finds what you left exposed.