Hidden Brecha of the SPA active credentials exposed in JavaScript bundles

Filtered API keys have long ceased to be an anecdote; however, the real size of the problem when these credentials appear within front-end code - specifically in JavaScript bundles - has remained largely invisible until recent studies. A technical team developed a new technique for detecting secrets and applied it to millions of applications with a clear objective: to analyse the devices that are deployed in production, not just the source code. The finding was strong and shows a worrying gap in the security chain of one-page applications (SPA).

In applying this methodology to scale, researchers generated an impressive volume of results: the output file occupied more than 100 MB in flat text and contained tens of thousands of tokens exposed that could correspond to real credentials. In concrete terms, the scan prayed for the emergence of thousands of different secrets, distributed in hundreds of different types, and many of them were not test keys or inactive tokens; they were credentials with real permission on services in production. This difference between "expired key" and "active credential with access" marks the gravity of the finding.

Among the most harmful exposures were tokens of repository platforms such as GitHub or GitLab. These credentials, when active and with extensive permissions, give the entry key to code and pipelines, and can provide access to additional secrets used in CI / CD integrations, cloud storage and SSH keys. They also appeared keys to project management tools that allow you to view internal tickets and organizational metadata, active chat and automation webbooks (including tens of Slack and Zapier), CAD software APIs with sensitive project information, document conversion services, commercial intelligence platforms and link shorters that allow you to create and list potentially dangerous URLs.

How is all this possible to reach the visible production bundles? The response is in a combination of failures in the software life cycle and in the limitations of the usual security tools. Many organizations rely on scanners operating on repositories or static source code analysis (SAST). These tools are valuable and detect credentials encoded directly into the repository files, but they do not always cover what happens later: the construction and deployment process can introduce, transform or mix artifacts so that the routes through which certain secrets enter do not match what is inspected in code control.

On the other hand, traditional infrastructure scanners or many automatic detection templates do very simple analyses: they request a base URL, inspect the direct response and apply regular expressions to search for known patterns. That works in many cases, but it has an obvious limit: it does not run the JavaScript of the page or download the bundles that the browser loads to render an SPA. As a result, the packed files containing tokens can remain outside the scope of these checks.

There are tools designed for dynamic scanning (DAST) that can run a headless browser, authenticate and go through the application more thoroughly, and therefore detect vectors that the static or infrastructure scanners do not reach. However, DAST is often more expensive, complex to configure and, in practice, applies to a small number of applications considered of high value. Maintaining a complete DAST for the entire application park of a company is rare, and in addition many implementations do not have all the regular signatures or expressions necessary to identify the variety of secrets that may appear.

A practical example of current limitations is the GitLab personal tokens detection template in ProjectDiscovery repositories for Nuclei. This template assumes a base URL, checks the initial response and, if you find a pattern that looks like a token, makes a call to the public API to confirm whether it is active. It is an effective logic in specific contexts, but it does not replace the ability to analyze all the resources a page loads when visiting a real browser, such as JavaScript bundles that often contain the secrets after construction (example of the repository: Nuclei template for GitLab personal tokens).

This leaves open a blind area that neither the repository scanners nor many infrastructure scanners cover, and that DAST only addresses if it is deployed on a large scale. The consequence is that secrets introduced during the build phase or by deployment pipelines can end up in production artifacts without the "shift-left" controls (those that push safety to early stages such as development and repository) detecting them.

In this context, the solution is not to abandon existing practices, but to complement them. Early checks in the development cycle and the integration of secret scanning in repositories and in CI / CD environments remain essential - for some reason reference agencies recommend secret management and early detection. OWASP, for example, offers guides on how to manage secrets and reduce exposure risk in development and production environments ( OWASP Secrets Management Cheat Sheet).

But, in addition, it is necessary to inspect the final artifacts that do reach the web: scan the published JavaScript bundles, simulate the execution of the SPA with an automated browser to download the resources that the client actually uses, and verify that there are no exposed tokens or sensitive endpoints. Scanning tools that analyze the files delivered in production and perform SPAs spidering help close this gap. In addition, public repository platforms have developed secret detection functions that should be activated; GitHub, for example, offers integrated secret scanning services to alert leaks in commons and repositories ( GitHub's documentation on secret scanning).

At the level of good operational practice, the recommendation is to minimize risk by restricting permits (the principle of less privilege), automatic rotation of key commitments and the adoption of secret management systems in which credentials are never part of the source code or static devices. It is also appropriate to review the use of tokens in third parties, limit their scope and audit who and what uses them. For specific tokens of platforms such as GitLab there is documentation on the use and limitations of personal access tokens that helps to design safer permissions ( GitLab: Personal access tokens).

The risk tends to increase as workflows are automated and the use of IA-generated code in pipelines grows: if validations migrate to automatic processes without adequate controls, valid credentials may be inserted into devices without sufficient human review. This is why the strategy should include scanning not only of the source code but also of the packages and bundles that reach customers, and integrated automated checks during the build phase to detect and block secrets before deployment.

The lesson is clear: the security of the front is not limited to the policies applied in the repository. The window that opens in the construction and delivery of artifacts must be closed. Tools that combine static analysis, dynamic with real navigation and scanning of deployed devices allow to detect problems that will otherwise be clear until an attacker finds them. For organizations with large application parks, the alternative is to risk critical credentials remaining visible in production and, thus, to an opportunistic access path for malicious actors.

If you want to go into work that specifically addresses this problem on a large scale or commercial solutions that already incorporate secret detection in SPA bundles, the research published by the teams that study this phenomenon and the pages of security providers offer useful resources to understand scope and mitigation. In addition to OWASP's guides and repository functionalities, review secret management practices and evaluate the inclusion of artifacts scans in your pipeline are practical and urgent steps to reduce exposure.