Researchers scanning 10 million webpages have found that nearly 10,000 pages contained live API credentials left in plain sight, potentially exposing access to services from cloud platforms to payment processors. The study, posted on arXiv in March 2026, identified 1,748 distinct API credentials tied to 14 service providers, with some keys sitting exposed for years before anyone noticed. The findings point to a systemic blind spot in how developers handle sensitive authentication tokens in client-side code.
What the Researchers Found
The paper, titled “Keys on Doormats: Exposed API Credentials on the Web,” was posted on arXiv, a preprint repository hosted by Cornell University Library with support from member institutions. Its authors analyzed 10 million webpages and flagged 1,748 unique API credentials scattered across nearly 10,000 individual pages. Those credentials belonged to 14 different service providers, meaning the problem was not confined to a single vendor or platform type.
Most of the exposed credentials were embedded directly in JavaScript, the language that powers nearly every interactive element on modern websites. Because JavaScript runs in the browser, any visitor with basic developer tools can inspect the page source and extract keys that were never meant to be public. The researchers noted that prior work on credential leakage had concentrated on mobile applications and code repositories such as GitHub, while “the web remains unexplored” as a vector for this kind of exposure, according to the full text of the paper.
Exposures Lasting Months to Years
One of the more striking details is the duration of these leaks. The researchers found that API credential exposures lasted anywhere from a single month to multiple years. That timeline suggests many site operators had no automated scanning or rotation policy in place to catch stale keys. In practice, a key that sits exposed for years gives any attacker a long window to discover it, test it, and exploit whatever access it grants.
The length of exposure also complicates remediation. Even after a key is removed from a webpage, the credential itself may still be valid on the provider’s side unless the site owner explicitly revokes it. If an attacker copied the key months ago, simply deleting the JavaScript line does nothing to close the door. This gap between “visible on the page” and “active on the backend” is a known problem in credential management, but the scale documented here shows how rarely teams address both sides.
Why JavaScript Is the Weak Link
The dominance of JavaScript as the source of leaked credentials is not a coincidence. Modern web development relies heavily on third-party APIs for everything from maps and analytics to payment processing and authentication. Developers routinely call these APIs from client-side scripts, and many quickstart guides from API providers include code snippets that place keys directly in the browser-facing layer. The convenience is obvious; the security tradeoff is less visible until a study like this quantifies it.
Server-side proxying, where the browser talks to the site’s own backend and the backend holds the key, is the standard mitigation. But it adds complexity, latency, and hosting cost. For small teams shipping features on tight deadlines, the temptation to drop a key into a JavaScript file and move on is strong. The result, as this research shows, is thousands of live credentials sitting in publicly accessible code.
Some API providers have tried to limit the blast radius by offering restricted keys that can only be used from specific domains or IP addresses. Google Maps, for example, lets developers lock keys to certain referrer URLs. But the paper’s findings across 14 providers suggest that either these restrictions are not widely adopted or they are configured too loosely to prevent misuse.
A Gap in Security Research
Previous studies on credential leakage focused heavily on source code repositories. GitHub has built automated secret-scanning tools that flag keys committed to public repos, and several third-party services offer similar detection. Mobile app binaries have also received attention, with researchers decompiling APK files to extract hardcoded tokens. The web, by contrast, received far less scrutiny despite being the most accessible attack surface of all. No decompilation is needed; the credentials are delivered to the browser in cleartext.
The authors framed their work as filling that gap. “In this paper, we study exposure of credentials on the web by analyzing 10M webpages,” they wrote, positioning the research as a direct complement to earlier mobile and repository-focused studies. Cornell University, whose infrastructure supports arXiv, has long served as a distribution point for security research of this kind. The Cornell Tech program maintains the platform alongside a broad base of institutional supporters.
Real-World Consequences of Leaked Keys
An exposed API key is not always catastrophic on its own. The severity depends on what permissions the key carries. A read-only analytics key might let an attacker view traffic data but not alter anything. A key tied to a cloud storage bucket or a payment gateway, on the other hand, could allow data exfiltration, unauthorized transactions, or service disruption.
The study did not publish a breakdown of which providers’ keys carried the highest risk, and the paper does not provide a comprehensive accounting of which of the 1,748 credentials were still active at the time of posting. Without vendor-side disclosure of how many of the 1,748 credentials were still active at the time of publication, the full scope of potential damage remains uncertain.
What is clear is the math of opportunity. Nearly 10,000 webpages means nearly 10,000 chances for an attacker running even a simple web scraper to harvest valid credentials. Automated scanning tools that replicate the researchers’ methodology appear feasible, which would lower the barrier to harvesting exposed credentials.
What Developers and Teams Can Do
The most direct fix is to stop shipping secrets to the browser. Any API key that grants write access, billing authority, or access to user data should live on the server, never in client-side JavaScript. Environment variables, secret managers like HashiCorp Vault or AWS Secrets Manager, and backend proxy endpoints all serve this purpose.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
