Researchers from three universities have found that nearly 10,000 webpages are publicly exposing API credentials, leaving sensitive services wide open to potential abuse. The team scanned 10 million webpages and identified 1,748 distinct credentials tied to 14 service providers, offering the first large-scale empirical evidence that the open web is littered with security keys hidden in plain sight.
What the Researchers Found
The study, authored by researchers at Stanford University, UC Davis, and TU Delft, systematically crawled 10 million webpages to detect API credentials embedded in publicly accessible code. Their results were stark: 1,748 distinct credentials from 14 service providers were sitting in the open, spread across thousands of sites. These are not credentials buried in private repositories or locked behind authentication walls. They are accessible to anyone with a web browser.
The paper, titled “Keys on Doormats: Exposed API Credentials on the Web,” was published as a preprint on arXiv, the open-access research platform operated through Cornell University. As the authors note, previous research into credential exposure focused heavily on mobile applications and code repositories like GitHub. However, the web itself had not been measured at comparable scale, leaving a significant blind spot in security research.
ArXiv’s role as a neutral, open repository is central to how this work is shared. The service is supported by a network of institutional partners listed among its member organizations, and it relies on community backing through voluntary donations to keep research like this freely accessible. Its operators also publish detailed help resources explaining submission and moderation policies, which shape how security papers are disseminated to practitioners and academics.
Why Client-Side Code Creates the Problem
The core mechanism behind these exposures is straightforward. Modern web development relies heavily on client-side JavaScript to handle everything from map rendering to payment processing. When developers embed API keys directly into front-end code, those keys ship to every visitor’s browser. Unlike server-side secrets, which stay behind a firewall, client-side credentials are readable by anyone who opens a browser’s developer tools or views the page source.
This is not a new risk in theory, but the scale documented by the Stanford, UC Davis, and TU Delft team gives the problem concrete dimensions for the first time on the open web. The 14 service providers whose credentials appeared in the dataset likely span cloud infrastructure, mapping services, payment gateways, and communication platforms, though the specific providers are discussed only in the full technical preprint. What matters is that each exposed key could, depending on the provider’s permission model, grant an attacker access to backend databases, user records, or billable services tied to the key owner’s account.
The trend toward single-page applications and heavy client-side rendering has accelerated this dynamic. Frameworks that bundle configuration files into browser-delivered JavaScript make it easy for a developer to accidentally include secrets in a production build. Build pipelines that lack automated secret-scanning steps compound the issue, turning a single configuration mistake into a live exposure that persists until someone notices.
Scale of Exposure Across the Web
The nearly 10,000 webpages flagged in the study represent a lower bound, not a ceiling. The researchers analyzed 10 million webpages in total, meaning the sample covered only a fraction of the billions of pages indexed by major search engines. Extrapolating from a roughly 0.1 percent hit rate across a much larger web suggests the true number of exposed credentials could be orders of magnitude higher.
That extrapolation comes with caveats. Not every exposed key carries the same risk. Some API providers issue public-facing keys that are designed to be embedded in client code, with restrictions enforced on the server side through domain whitelisting, usage caps, or tightly scoped permissions. The danger escalates when keys carry broad privileges, lack IP or domain restrictions, or belong to services that do not clearly distinguish between public and private credential types.
The paper’s finding of 1,748 distinct credentials across 14 providers underscores that this is not an isolated misconfiguration. Even if a portion of those keys are low-impact, the sheer diversity of services involved increases the odds that at least some grant access to sensitive backend resources or high-value billing capabilities.
A Gap in Security Research
Security researchers and automated scanning tools have spent years combing GitHub, GitLab, and other code-hosting platforms for leaked secrets. Services like GitHub’s secret scanning and third-party tools such as TruffleHog have made repository-level detection routine. Mobile app analysis has similarly matured, with decompilation tools making it possible to extract hardcoded keys from Android and iOS binaries.
The web, by contrast, has received far less systematic attention. The “Keys on Doormats” paper, which appears on the Cornell Tech arXiv portal, argues that this gap is not justified by lower risk but by the absence of measurement. The researchers’ decision to scan live webpages rather than static code repositories reflects a recognition that deployed credentials pose a more immediate threat than keys sitting in a developer’s uncommitted branch. A key in a public webpage is already in production, already reachable, and already exploitable.
This distinction matters for how organizations prioritize their security tooling. Companies that invest in pre-deployment secret scanning but ignore what their build pipelines actually ship to browsers may be addressing the wrong stage of the problem. Without visibility into client-side bundles and static assets, even mature development teams can miss high-impact leaks.
What Exposed Keys Mean for Everyday Users
For the average person visiting a website, the presence of an exposed API key is invisible. There is no browser warning, no broken padlock icon, no sign that the site’s developer left a sensitive credential in the page’s source code. But the consequences can be direct. If an attacker harvests an exposed key that grants access to a cloud database, the data at risk could include user emails, hashed passwords, payment details, or personal messages stored by the service.
The financial exposure extends to the key’s owner as well. Cloud providers typically bill by usage, and a stolen API key tied to a compute or storage service can generate thousands of dollars in charges before the owner detects the abuse. In cases where the key controls a messaging or email API, attackers can use it to send spam or phishing campaigns that appear to originate from a legitimate business, eroding user trust and potentially triggering blacklisting by other providers.
None of this requires sophisticated hacking. The credentials identified in the study were sitting in publicly served files. An attacker needs only a script that fetches pages and searches for known key patterns, a technique well within reach of entry-level threat actors. Once discovered, those keys can be tested against provider APIs to see which ones still work, turning a passive scan into active exploitation.
What Developers and Organizations Can Do
The most effective defense is architectural: avoid putting secrets in client-side code at all. Any operation that requires a privileged credential (whether it is accessing a database, talking to a third-party API, or initiating a payment) should be routed through a server under the organization’s control. The browser talks to that server, which in turn uses stored credentials that never leave the backend environment.
Where client-side keys are unavoidable, organizations should treat them as public identifiers, not secrets. That means scoping them to the minimum necessary permissions, enforcing strict domain and IP restrictions where providers support them, and monitoring usage patterns for anomalies that could indicate abuse. Keys that grant write access, administrative control, or high-cost operations should never be embedded in front-end code.
Build and deployment pipelines also need to incorporate automated checks. Secret-scanning tools can be integrated into continuous integration workflows to flag suspicious patterns before code reaches production. Crucially, those scans should run not only on source repositories but also on the compiled assets that will be served to users, catching credentials that might be introduced or transformed during bundling and minification.
Finally, organizations should plan for the inevitability of leaks. That includes maintaining an inventory of issued API keys, rotating them regularly, and having a clear procedure for revoking and replacing credentials when exposure is detected. Logging and alerting around key usage can shorten the window between compromise and response, limiting both data loss and financial damage.
The new research makes clear that exposed credentials on the open web are not a hypothetical edge case but a measurable, widespread phenomenon. Treating client-side code with the same rigor applied to repositories and mobile binaries is no longer optional; it is a baseline requirement for keeping both users and infrastructure safe.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
