Leaked API keys and the subsequent security breaches are becoming alarmingly common, yet sensitive tokens continue to be exposed with surprising ease. Intruder’s research team investigated why this vulnerability persists, examining the shortcomings of traditional vulnerability scanners and developing a novel method for secrets detection that addresses these gaps.
By applying this new approach to scan five million applications, researchers uncovered over 42,000 exposed tokens across 334 different types. This discovery highlights a significant category of leaked secrets, particularly within single-page applications (SPAs), that current security tools are failing to adequately address. This article delves into existing secrets detection methods, their limitations, and the findings from this large-scale scan of JavaScript bundles.
Established Secrets Detection Methods and Their Limitations
Traditional Secrets Detection
The conventional, fully automated method for identifying application secrets involves scanning predefined paths and using regular expressions to match known secret formats. While this technique can uncover some exposures, it has inherent limitations and cannot detect all forms of leaks, especially those requiring application spidering or authentication.
For instance, a common approach, exemplified by tools like Nuclei with its GitLab personal access token template, operates by making a single HTTP GET request to a provided base URL. It then inspects the direct response, crucially ignoring other resources such as JavaScript files. The template attempts to identify the pattern of a GitLab personal access token and, if found, makes a follow-up request to the GitLab API to verify its activity. If active, an issue is raised.
This method is effective when templates define numerous paths where secrets are commonly found. However, this tactic is typical of infrastructure scanners that do not employ a headless browser. Consequently, requests that a browser would naturally make to fetch necessary JavaScript files for rendering a page are not performed by this older approach.
Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing (DAST) tools offer a more comprehensive approach to application security scanning. They typically feature more advanced functionalities, enabling full application spidering, support for authentication, and enhanced detection of application-layer weaknesses. DAST scanners might seem like the logical choice for discovering secrets within application front-ends, as they should be capable of identifying and scanning available JavaScript files.
However, DAST scanning is often more resource-intensive, demands in-depth configuration, and is typically reserved for a limited number of high-value applications due to cost and complexity. It’s impractical to configure DAST for every application across a broad digital estate. Furthermore, many DAST tools lack the extensive range of regular expressions found in dedicated command-line tools.
This creates a void that traditional infrastructure scanners, while effective in their domain, do not fill. Similarly, DAST scanners often fail to address this gap due to deployment, budget, and maintenance constraints.
Static Application Security Testing (SAST)
Static Application Security Testing (SAST) tools analyze source code to identify vulnerabilities and are a primary method for detecting secrets before code reaches production. They excel at identifying hardcoded credentials and preventing certain types of exposure. Despite their effectiveness, SAST methods also do not provide a complete picture, and as this research found, some secrets embedded within JavaScript bundles can still slip through the cracks, bypassing static analysis.
Building a Secrets Detection Check for JavaScript Bundles
Initial research sought to determine the prevalence of secrets being bundled into JavaScript front-ends. To ascertain if this was a widespread issue warranting an automated solution, an automated check was developed and applied to approximately five million applications.
The results revealed a significantly higher number of exposures than anticipated. The output itself exceeded 100MB of plain text and contained more than 42,000 tokens covering 334 distinct secret types. While not every result was fully triaged, a review of sampled exposures identified several with high impact.
Key Findings from the Scan
Code Repository Tokens
Among the most critical exposures were tokens for code repository platforms like GitHub and GitLab. The scan detected 688 such tokens, many of which remained active and provided full access to repositories. In one notable instance, a GitLab personal access token was directly embedded within a JavaScript file. This token granted unrestricted access to all private repositories within an organization, including sensitive CI/CD pipeline secrets for services like AWS and SSH.
Project Management API Keys
Another significant finding involved an API key for Linear, a project management application, which was also found directly in front-end code. This exposed token provided access to the organization’s entire Linear instance. This included internal tickets, project details, and connections to downstream services and SaaS projects, posing a considerable data security risk.
Broader Secret Exposures
The research identified exposed secrets across a wide array of other services. These included API access for CAD software, potentially exposing user data, project metadata, and building designs. Exposed secrets were also found in link shorteners, allowing for unauthorized link creation and enumeration. Email platforms exposed mailing lists, campaigns, and subscriber data. Webhooks for chat and automation platforms revealed 213 active Slack tokens, 2 Microsoft Teams tokens, 1 Discord token, and 98 Zapier tokens.
Additionally, exposures were noted for PDF converters, granting access to third-party document generation tools, and sales intelligence and analytics platforms, which could compromise scraped company and contact data.
Preventing Secrets in Production Code
“Shift-left” security controls, such as SAST, repository scanning, and IDE integrations, are vital for catching vulnerabilities early in the development lifecycle and preventing entire classes of exposure. However, as this research demonstrates, these controls do not cover every pathway through which secrets can reach production environments.
Secrets introduced during the build and deployment phases can bypass these initial safeguards and end up embedded in front-end code. This problem is likely to escalate with the increasing adoption of automation and the use of AI-generated code. As a result, single-page application spidering capabilities are essential to detect secrets before they are deployed into production.
Intruder has integrated automated SPA secrets detection into its platform to help teams identify these hidden risks. Further details on this capability can be found on their website.