Secrets traveling with the bundle: millions of apps expose tokens in the browser and how to stop it

API key and tokens leaks were no longer a rarity. In recent years we have seen how secrets that should remain in closed environments end up circulating in public repositories, container images and, increasingly, within the own code that is sent to the browser. Why do these leaks continue to occur when there are so many tools and practices to avoid them? After investigating how the different approaches to the detection of secrets work and developing a specific check for JavaScript bundles, the result was surprising: the analysis of millions of applications found tens of thousands of tokens exposed, many of them active and with powerful permissions.

Classical methods for searching for secrets are often based on two pillars: knowing common routes where credentials can be left and applying patterns (usually regular expressions) that identify known tokens formats. This fully automated technique provides useful and rapid results, and is the one that many infrastructure scanners use. However, it has an obvious limit: if the search engine is conformed to asking for the root page of a domain and does not reproduce the requests a browser makes - such as downloading JavaScript files - many secrets never go ahead of the detector. A real example of template following this pattern can be seen in ProjectDiscovery repositories for Nuclei, where checks are described that inspect direct responses to specific HTTP requests and act accordingly: Nuclei template for GitLab personal tokens.

On the other hand, dynamic safety tests (DAST) seem, in theory, a good option for detecting secrets on the front-end because they can emulate the actual navigation, track the application and understand flows that require authentication. In practice, running DAST in a comprehensive way is more expensive and requires advanced configuration, so many organizations reserve it to a limited number of critical applications. In addition, not all DAST scanners incorporate the same range of detection patterns as tools specialized in the search for secrets.

Static code verification (SAST) is another element of the arsenal: it analyzes the source code to prevent secrets from coming to production and is very effective in many scenarios. But JavaScript bundles used in modern web applications, especially in the Single-Page Applications (SPA), can be built in stages after static analysis or with building processes that inject variables. This allows new secrets to appear in compiled artifacts without going through the controls running SAST, so a purely static analysis of the repository does not always detect what is finally served to the customer.

With these limitations in mind, a check was designed to examine the JavaScript bundles that can be downloaded by a browser. It was put to work on a scale: approximately five million applications were tracked looking for tokens patterns within the files served to the client. The overturn of results exceeded 100 MB of text and released more than 42,000 matching credentials with 334 different types of secrets. Not all of the findings were manually tripled, but among the verified samples high-impact exposures appeared to illustrate the problem well.

Among the most serious cases, tokens were detected for code repository platforms. In total, 688 tokens were linked to services such as GitHub and GitLab, and a relevant part remained in force, allowing access to private repositories. In a specific instance, a GitLab personal token was located in a JavaScript file, granting extensive organizational permits, including pipeline secrets and access that facilitate side movements to services such as AWS or SSH access. GitLab's official personal tokens documentation is a good reference point for understanding the risks of exposing them: GitLab - Personal access tokens. Similarly, GitHub maintains guidelines on the creation and management of tokens that should be known: GitHub - Personal access tokens.

Another notable exposure affected API keys for project management tools. Linear tokens were located in front-end code inserts that allowed you to read tickets, internal projects and links to integrations that in turn could provide access to other assets and services. Beyond these examples, the scan found credentials related to APIs of computer-assisted design software, link shorters with ability to create and list URLs, email marketing platforms with access to lists and campaigns, chat and automation platforms webbooks - including hundreds of active endpoints of Slack, Microsoft Teams, Discord and Zapier -, PDF converters and commercial intelligence tools that exposed contact databases. These findings confirm that the risk area is not limited to a few suppliers but covers a wide range of integrations and services.

What practical lessons are derived from all this? First, the measures of "shift-left" - to analyse and prevent from the early stages of development - remain fundamental. SAST tools, repository scanners, and IDE plugins detect many bad practices before the code leaves the development environment. However, they are not enough on their own: any secret introduced in build phases or during the deployment configuration can avoid those controls and end up packed in a bundle served to the browser.

It is therefore essential to incorporate checks that reproduce the real behavior of a web client: download the JS files that the application delivers, inspect them in search of tokens patterns and validate the activity of the detected credentials. This approach requires mechanisms that interpret the same resource tree that a browser gets when loading an SPA and also perform automated checks to determine whether a token remains valid. The security community and good practice guides contain recommendations for managing secrets - for example, the OWASP Secret Management Cheat Sheet- that it is appropriate to integrate with detections in time of execution.

As far as specific mitigation is concerned, organisations should, as far as possible, prevent any credential with sensitive permits from reaching the customer. Instead, applications should delegate calls to services on controlled servers, use key-hiding proxys, use short-lived tokens and apply the principle of minor privilege. In addition, activating and complementing the scanning of secrets offered by suppliers such as GitHub - see your secret detection service - helps intercept leaks in the code and published artifacts: GitHub - Secret scanning.

The picture also evolves by increasing automation and the use of code generated by IA tools: if automated pipelines are not configured to protect secrets, the risk of introducing credentials into compiled artifacts will increase. The solution goes by combining static check-ups in the development flow, repository scans, controls during compilation and dynamic detection that simulate the download and inspection of the bundles that reach the browser. For SPA applications specifically, this involves incorporating spidering and downloading static resources as part of the security process, rather than just asking only for the home page.

Detecting and removing exposed secrets in bundles is not a trivial task, but evidence shows that it is essential: when millions of applications were analyzed, tens of thousands of exposed tokens and hundreds of different types of secrets appeared. Adopt a multi-layer strategy, update CI / CD processes to avoid injecting credentials into public artifacts, and run scans that replicate the actual browser experience are necessary steps to significantly reduce this risk. If you want to deepen the differences between static and dynamic analysis and better understand when to use each technique, OWASP's resources on safety analysis are a good starting point: OWASP - Source code analysis and OWASP - Dynamic analysis.

In short, the problem is clear: secrets should not travel to the browser, but with current building, deployment and automation processes that continues to happen. The response is not a single tool but a combination of good practice, pipeline controls and detection that inspects exactly what the browser downloads. Only in this way can we reduce the likelihood that a committed token will be the gateway to much more valuable assets.