Researchers at Stanford and UC Davis just published a study that should make every API team uncomfortable. They scanned roughly 10 million web pages, ran TruffleHog against every one of them, and found 1,748 verified, live API credentials scattered across 9,804 websites spanning 5,693 distinct domains. The credentials belonged to multinational corporations, critical infrastructure entities, and government agencies. AWS keys. Stripe keys. OpenAI keys. All sitting in plain sight on the public internet.
The paper is called “Keys on Doormats: Exposed API Credentials on the Web”, and it landed during a week where every major tech outlet picked it up — The Register, CyberNews, and IBTimes all ran coverage. The timing is not a coincidence. API credential exposure is not a niche problem anymore. It is the default state of the web.
The Scale of the Problem
The study examined 14 major service providers and verified every credential it found. The results break down like this:
- AWS — 283 verified credentials exposed across 4,693 websites. One belonged to a Global Systemically Important Financial Institution (G-SIFI) with access to Lambda, RDS, and Key Management Service.
- Stripe — 277 credentials with a 42% verification rate. Live payment processing keys sitting in production JavaScript bundles.
- OpenAI — 181 credentials with an 18% verification rate. The rapid adoption of AI APIs is creating a new generation of key sprawl.
- GitHub — 119 credentials, including one that granted full repository privileges to a firmware developer whose code powers drones and remote-controlled devices globally.
And here is the part that should really keep you up at night: exposed credentials remained publicly accessible for an average of 12 months. Some persisted for up to five years. The majority went unaddressed for months.
JavaScript Build Tools Are the #1 Vector
The most actionable finding in the study is the root cause analysis. 84% of exposed credentials appeared in JavaScript resources, and of those, 62% were inside bundled files generated by tools like Webpack. Only 8% appeared in HTML resources.
This means the majority of credential leaks are not developers accidentally
pasting a key into an HTML template. They are build tools — Webpack, Vite,
Rollup — pulling environment variables into client-side bundles during the build
process. A developer sets REACT_APP_API_KEY or NEXT_PUBLIC_STRIPE_KEY in
their .env file, and the bundler dutifully bakes it into a JavaScript file
that gets served to every visitor.
The encoding makes it worse, not better. The study found that 67% of credentials were exposed in plain text, 18% as escaped Unicode sequences, and 15% as Base64-encoded strings. None of these are security measures. They are artifacts of how JavaScript bundlers serialize string values. Anyone with browser DevTools can decode them in seconds.
The researchers put it bluntly: the root cause is that build-time environment
variable substitution treats all variables the same, whether they hold a
public site title or a secret AWS access key. Frameworks like Next.js and Create
React App use prefixes (NEXT_PUBLIC_, REACT_APP_) to mark variables as safe
for client-side inclusion, but the study shows that developers routinely ignore
or misunderstand these conventions.
The $82K Connection
If this sounds familiar, it should. Just three weeks before this study dropped, we wrote about the Google Gemini API key vulnerability where nearly 3,000 public Google API keys — originally harmless billing identifiers for services like Maps — silently gained access to Gemini AI endpoints. One developer racked up $82,314 in charges in a single day.
The Stanford study validates the same pattern at a much larger scale. Keys that were embedded in client-side code years ago, when the perceived risk was low, are now sitting on a web that has fundamentally changed around them. AWS keys that once accessed a single S3 bucket might now reach services the developer never intended. Stripe test keys might have been promoted to production. OpenAI keys that cost pennies per call in 2024 now access models that cost dollars per call.
The blast radius of an exposed key is not static. It grows every time the backing service adds a new capability or changes its pricing. And the Stanford data shows that keys stick around for months or years — long enough for the risk profile to shift dramatically beneath them.
The Fix the Researchers Recommend
The paper’s recommendations read like a product requirements document for an API gateway. The researchers explicitly call for:
- Routing sensitive API calls through backend proxies instead of making them directly from client-side JavaScript
- Using separate, easily rotatable keys rather than long-lived static credentials
- Integrating credential scanning into CI/CD pipelines to catch leaks before they reach production
- Service providers deploying automated detection of leaked keys on public webpages
These are not theoretical suggestions. They are describing the architecture that an API gateway like Zuplo provides out of the box.
How Zuplo Addresses Every Root Cause
The Stanford study identifies a clear chain of failures: keys get embedded in client code, build tools bake them into production bundles, and they persist for months because nobody detects or rotates them. Zuplo breaks this chain at multiple points.
Backend Proxy Architecture: Keep Keys Server-Side
The single most effective fix is also the simplest: do not put secret keys in client-side code. Period.
Zuplo sits between your frontend and your backend APIs as a
fully managed API gateway.
Your frontend authenticates to Zuplo using a consumer-specific API key, and
Zuplo handles the upstream call to AWS, Stripe, OpenAI, or any other service
using server-side credentials that never touch a JavaScript bundle. The secret
keys stay in Zuplo’s
secure environment variable storage
— not in your .env file, not in your Webpack config, and certainly not in your
production HTML.
This is exactly what the Stanford researchers recommend when they call for “routing sensitive API calls through backend proxies.”
Managed API Key Authentication: No More DIY Key Management
Zuplo’s API key authentication gives your API consumers keys that are purpose-built for secure distribution. Keys are stored as irretrievable, one-way hashes — the original key value cannot be reconstructed even if the underlying storage is breached. Each key is scoped to a specific consumer with its own metadata, permissions, and rate limits.
Because consumers get their keys through Zuplo’s
developer portal — not by copying values
from a .env file — there is no reason to embed keys in build-time
configuration at all. The pattern that caused 84% of the exposures in the
Stanford study simply does not exist.
Instant Key Rotation: Months of Exposure Become Seconds
The Stanford data shows that exposed credentials remained live for an average of 12 months. Even after the researchers notified 2,435 affected organizations, only 50% removed the exposed credentials within 14 days — and just 26% actually revoked the keys (meaning the rest only removed the public exposure while leaving the credentials active).
Zuplo supports instant key rolling through both the API and the developer portal. Rolling a key creates a new credential and sets an expiration on all existing keys for that consumer — you can expire them immediately for maximum security or set a short grace period so consumers have time to update. Changes propagate globally across Zuplo’s 300+ edge locations in seconds, not hours.
GitHub Secret Scanning: Catch Leaks Before They Go Live
Here is where Zuplo closes a gap the study specifically calls out. The researchers recommend that service providers “deploy automated detection of leaked keys.” Zuplo has been doing this since 2022.
Zuplo is an official
GitHub secret scanning partner.
Every Zuplo API key uses a distinctive zpka_ prefix that GitHub’s scanners
recognize. If a Zuplo-issued API key is accidentally committed to any GitHub
repository — public or private — GitHub notifies Zuplo, and Zuplo immediately
alerts you via email and in-app notifications. From there, you can
roll the key with a
single API call or portal click.
This is not a premium add-on. API key leak detection is available to every Zuplo customer, including free tier. The Stanford study found that 62% of leaked credentials were buried in Webpack bundles where manual code review would never catch them. Automated scanning is the only realistic defense at scale, and Zuplo bakes it into the platform by default.
Per-Key Rate Limiting: Cap the Blast Radius
Even with leak detection and fast rotation, defense in depth matters. If a key is compromised before you can rotate it, rate limits are your circuit breaker.
Zuplo’s rate limiting policies can be configured per API key, so every consumer gets their own ceiling. You can set request-per-minute limits, daily quotas, or custom policies based on consumer metadata. This is the difference between a compromised key generating an $82,000 bill and a compromised key hitting a rate limit after $50 of usage.
The Bigger Picture
The Stanford study is the latest in a pattern that is becoming impossible to ignore. In February, the Google Gemini API key incident showed what happens when exposed keys gain new privileges. In March, Wallarm’s 2026 API ThreatStats Report confirmed that APIs are now the #1 exploited attack surface, with 59% of API vulnerabilities requiring no authentication at all.
The common thread across all three is that ad-hoc API credential management does not work. It does not work for startups. It does not work for enterprises. The Stanford study found exposed keys belonging to organizations of every size, including financial institutions and government agencies. If well-resourced teams with dedicated security staff are failing at this, the answer is not “try harder at DIY key management.” The answer is to use infrastructure that makes the insecure path impossible.
That means: backend proxies so secrets never reach client code. Managed key authentication so credentials are hashed, scoped, and rotatable. Automated leak detection so exposure is measured in minutes, not months. Per-key rate limits so a compromised credential cannot cause catastrophic damage.
That is what Zuplo provides. If you want to see how it works, start for free and add API key authentication to your API in minutes. For a deeper dive into implementation patterns, read our guide on how to implement API key authentication or explore the API key authentication best practices.