Exposed API Credentials: What 10 Million Websites Reveal

In March 2026, researchers from Stanford University, UC Davis, and TU Delft published a paper titled "Keys on Doormats: Exposed API Credentials on the Web." The idea was to see how many webpages have exposed APIs.

So they scanned 10 million webpages and found 1,748 active API credentials that grant access to AWS, GitHub, Stripe, OpenAI, and Twilio accounts. These websites, amongst others, belonged to global banks, healthcare providers, and government agencies.

The 1,748 number is likely way higher. The researchers could only validate credentials they tested; passive, rotated, or indirectly embedded keys didn’t appear in that count. The organizations affected had running production environments, real customers, and presumably some form of developer security tooling. None of that stopped credentials from shipping in their JavaScript bundles.

API credential exposure occurs when authentication keys, tokens, or secrets embedded in web code are accessible to anyone who inspects a webpage's source, including attackers scanning at scale. Unlike a data breach, the organization typically has no record of the exposure and no way to know whether it was exploited.

What 10 Million Websites Actually Showed

The researchers scanned public webpages across 10 million domains and extracted credentials using pattern recognition. What they found was distributed across 10,000 of those sites — one in every thousand, across sectors, geographies, and organization sizes.

AWS credentials made up more than 16% of all verified exposures. AWS credentials typically carry IAM permissions that extend well beyond the specific service the developer intended to use. A leaked S3 access key can mean access to buckets. A leaked Lambda execution role can mean access to internal services. The blast radius is a function of what was granted, not what was intended.

Across 10,000 affected sites, the services exposed included OpenAI (with direct implications for any organization handling sensitive prompts or completions), Stripe and Twilio (payment and communications infrastructure), and GitHub (source code access, potentially including private repositories and CI/CD pipelines).

Why the Build Pipeline Is the Root Cause

Sixty-two percent of JavaScript-based credential exposures occurred in bundles produced by tools such as Webpack. The majority of leaks were introduced during the build process, where environment variables, configuration files, or hardcoded strings are bundled into artifacts shipped to production.

This is a process problem because most developers working with these tools know that API keys shouldn't be in client-side JavaScript. The issue is that build pipelines are not consistently audited for what gets included, and the gap between a developer's intent ("this key is server-side only") and the reality ("this key is now in a Webpack bundle that ships to every browser") is invisible without active scanning of production output.

The 12-month average exposure duration is the number that should concern platform leaders most. The keys had been alive for approximately a year before researchers happened upon them. For every credential included in the study, there may be many more on the same sites that didn't match the researchers' detection patterns — embedded in different formats, in third-party scripts, or in infrastructure beyond the scanned scope.

After the research team began notifying affected organizations, approximately half of all exposed credentials were rotated or removed within two weeks. The other half were not.

What Exposed API Credentials Actually Unlock Downstream

It’s not the exposure, but what someone could with that exposed key. And would a solution architect even know?

• An exposed Stripe key with write permissions can initiate refunds, modify customer records, or exfiltrate transaction data.

• An exposed OpenAI key can send arbitrary requests against an organization's account, including requests that read conversation history, bypass configured guardrails, or run up cost in a way that masquerades as legitimate usage until the invoice arrives.

• An exposed GitHub token with repo access can clone private code, read CI/CD secrets, or push code to branches.

None of those actions trigger an alert in the system where the key was exposed. They trigger anomaly detection in the API layer, where the traffic pattern, the requesting context, and the payload can be compared against what normal looks like for that credential. Without that layer, the exposure is silent: no alert, no log entry attributed to the breach, no way to reconstruct what was accessed after the fact.

This is the gap that passive secrets scanning does not address. Pre-deployment scanning is valuable and should be part of any pipeline. But a credential that made it past scanning, was introduced after the last scan ran, or exists in a legacy system outside the scanning perimeter, is invisible until someone uses it maliciously or a researcher happens to find it on a public webpage.

Treblle operates at the API request level, after the credential is used, capturing the full context of what was called, what was returned, who authenticated the request, and whether the request pattern is consistent with legitimate use.

When a credential is used from an unexpected IP range, at an unusual hour, at a volume that doesn't match the account's normal pattern, or against endpoints the account hasn't previously accessed, Treblle flags it even before it becomes a breach. Across more than one billion API requests Treblle processes monthly, request-level anomaly detection is what catches the exposures that pre-deployment scanning missed.

What This Means for Platform Leaders

For CIOs and solution architects overseeing API-dependent products, the Keys on Doormats findings frame three questions worth examining:

Are you scanning production artifacts, not just source code? Most secrets scanning tools integrated into CI/CD pipelines scan code at commit time. A key hardcoded in a build configuration file that only resolves at bundle time will pass commit-level scans. Production artifact scanning requires a different integration point.

Do you have a credential inventory with rotation schedules? The study found credentials exposed for an average of 12 months. Even if they were introduced accidentally, a team with a live credential inventory and rotation schedule would have rotated those keys before they became a liability. Most teams don't have this inventory; it lives across CI/CD environment configs, local developer setups, and legacy deploy scripts that nobody has looked at since the original engineer left.

Can you detect anomalous use of a credential after the fact? If an attacker used a leaked Stripe key six months ago and made 40 read API calls over three days before abandoning it, could you find that in your logs now? The answer determines whether an exposure becomes a confirmed breach or a potential breach, and regulators treat those differently.

Treblle answers the third question directly: request-level capture tied to authentication context, queryable after the fact, with real-time anomaly alerting. The first two require process changes; the third requires the right instrumentation in place before the incident, not after.

The significance of the study is that a research team found credential exposure at this scale after scanning public webpages over a few weeks. The same scan is available to anyone with the same tooling and intent, and adversarial actors aren't publishing their findings.

If you want to understand what your production API traffic looks like against the credentials your platform uses, Treblle gives you that picture without touching your existing secrets management setup.

Frequently Asked Questions