What 5 Million Apps Revealed About Secrets in JavaScript

Source: Bleeping Computer

Overview

Leaked API keys are nothing new, but the scale of the problem in front‑end code has been largely a mystery—until now.
Intruder’s research team built a new secrets‑detection method and scanned 5 million applications, specifically looking for secrets hidden in JavaScript bundles.

What we found revealed a massive gap in how the industry secures single‑page applications.

42,000 Secrets Hidden in Plain Sight

The results of applying our new detection method at scale were staggering. The output file alone was > 100 MB of plain‑text data, containing more than 42 000 exposed tokens across 334 secret types.

These weren’t low‑value test keys or dead tokens. We uncovered active, critical credentials embedded in production code, effectively bypassing the security controls most organizations rely on.

Below is a breakdown of the most critical risks we discovered.

Code‑Repository Tokens

The most impactful exposures were tokens for code‑repository platforms such as GitHub and GitLab. In total we found 688 tokens, many still active and granting full repository access.

Example: a GitLab personal‑access token hard‑coded in a JavaScript file. The token was scoped to allow access to all private repositories in the organization, including CI/CD pipeline secrets for downstream services (AWS, SSH, etc.).

Project‑Management API Keys

Another significant exposure involved an API key for Linear, a project‑management tool, embedded directly in front‑end code.

The token gave unrestricted access to the organization’s entire Linear instance—internal tickets, projects, and links to downstream SaaS services.

Other Exposed Secrets

We identified secrets across a wide range of additional services:

• CAD software APIs – access to user data, project metadata, and building designs (including a hospital).
• Email platforms – access to mailing lists, campaigns, and subscriber data.
• Webhooks for chat/automation platforms – 213 Slack, 2 Microsoft Teams, 1 Discord, and 98 Zapier webhooks, all active.
• PDF converters – access to third‑party document‑generation tools.
• Sales‑intelligence & analytics platforms – access to scraped company and contact data.
• Link shorteners – ability to create and enumerate short links.

Takeaway: Secrets embedded in source code—especially front‑end assets—are a massive attack surface. Regular automated scanning, secret‑management policies, and strict CI/CD hygiene are essential to prevent such exposures.

Why Are These Secrets Being Missed?

Traditional Scanners Don’t “Speak” JavaScript

The traditional, fully‑automated approach to detecting application secrets is to:

1. Search a set of known paths.
2. Apply regular expressions to match known secret formats.

While useful, this method has clear limitations and will not detect all types of leaks—especially those that require the scanner to spider the application or authenticate.

Example: Nuclei’s GitLab personal access token template

When the scanner is fed a base URL (e.g., https://portal.intruder.io/), the template:

1. Makes an HTTP GET request to https://portal.intruder.io/.
2. Inspects only the direct response, ignoring other pages and resources such as JavaScript files.
3. Attempts to identify the pattern of a GitLab personal access token.
4. If found, makes a follow‑up request to GitLab’s public API to check whether the token is active.
5. If active, raises an issue.

This flow works well when templates define many common paths where secrets are exposed. However, it is typical of infrastructure scanners, which do not run a headless browser. Consequently, resources that a browser would request—e.g., the JavaScript bundle https://portal.intruder.io/assets/index-DzChsIZu.js—are never fetched.

The “Build Process” Blind Spot

Static Application Security Testing (SAST) tools analyze source code to identify vulnerabilities and are a primary way to detect secrets before they reach production. They excel at catching hard‑coded credentials.

However, we found that SAST does not cover the full picture: some secrets embedded in JavaScript bundles slip through the gaps that static analysis cannot detect.

The DAST Dilemma

Dynamic Application Security Testing (DAST) tools are generally more robust for scanning applications. They can:

• Spider the entire site.
• Support authentication.
• Detect a broader range of application‑layer weaknesses.

In theory, DAST should be the natural choice for secret detection in front‑ends, as it can retrieve JavaScript files and scan them for secrets. In practice, though:

• DAST is expensive and requires extensive configuration.
• It is usually reserved for a small number of high‑value applications.
• Many organizations do not configure a DAST scanner for every application across a large digital estate.
• Some DAST tools lack the comprehensive set of regular expressions that dedicated command‑line secret scanners provide.

The Resulting Gap

The combination of:

• Traditional infrastructure scanners that don’t fetch JavaScript assets, and
• Limited SAST coverage of bundled code, plus
• Infrequent or under‑configured DAST deployments

creates a clear blind spot where secrets can remain undetected. This gap needs to be addressed with a solution that can efficiently analyze JavaScript bundles without the cost and complexity of full‑scale DAST.

Keep Your Secrets Secret

Shift‑left controls matter. SAST, repository scanning, and IDE guardrails catch real issues and prevent entire classes of exposure. But, as this research shows, they don’t cover every path a secret can take into production.

Secrets introduced during build and deployment can bypass those safeguards and end up in front‑end code—long after the point where shift‑left controls have already run. This problem will only grow as automation and AI‑generated code become more common.

That’s why single‑page‑application (SPA) spidering is needed to catch secrets before they reach production. We’ve built automated SPA secrets detection into Intruder so teams can actually catch this.

Learn more

Author

Ben Marr – Security Engineer, Intruder

Ben is a Security Engineer at Intruder, where he automates offensive security scanning and conducts security research. His background includes OSWE‑certified penetration testing and PHP software engineering.

Sponsored and written by Intruder.