Full Report
Leaked API keys are no longer unusual, nor are the breaches that follow. So why are sensitive tokens still being so easily exposed? To find out, Intruder’s research team looked at what traditional vulnerability scanners actually cover and built a new secrets detection method to address gaps in existing approaches. Applying this at scale by scanning 5 million applications revealed over
Analysis Summary
# Tool/Technique: Secrets Exposure in JavaScript Bundles (General Finding)
## Overview
This is a summary of a research finding by Intruder's team identifying the widespread exposure of sensitive tokens (over 42,000 across 334 secret types) due to weaknesses in traditional security scanning methods, particularly concerning secrets embedded within JavaScript bundles in modern applications, such as Single-Page Applications (SPAs).
## Technical Details
- Type: Technique (Misconfiguration/Exposure)
- Platform: Web Applications (specifically those leveraging JavaScript for front-end logic)
- Capabilities: Exposure of sensitive data (API keys, tokens, credentials) embedded in client-side code.
- First Seen: Ongoing issue, highlighted by recent research findings.
## MITRE ATT&CK Mapping
Since this is a general exposure finding and not a specific piece of malware or tool, the primary mapping relates to Initial Access or Persistence mechanisms that an attacker could leverage after discovery.
- **TA0001 - Initial Access**
- T1566 - Phishing (If the discovered token is used in a subsequent attack)
- T1190 - Exploit Public-Facing Application (If the exposed token circumvents an authentication mechanism)
- **TA0003 - Persistence**
- T1552.001 - Credentials from Configuration Files (If tokens are treated as stored credentials)
## Functionality
### Core Capabilities
- **Exposure Location:** Secrets (tokens, keys) are being inadvertently committed or injected into publicly accessible artifacts like JavaScript bundles (e.g., `index-DzChsIZu.js`).
- **Discovery Method:** Exploits limitations of traditional scanners that do not fully spider applications or analyze dynamically loaded resources like JS files.
### Advanced Features
- **Impact on SPAs:** The issue is particularly prevalent in Single-Page Applications (SPAs) where heavy reliance on client-side bundling exposes more surface area.
- **Evasion:** The secrets bypass traditional infrastructure scanners that only check base URLs or pre-defined paths without executing client-side content.
## Indicators of Compromise
This section focuses on the *result* of the technique (the exposed secret) rather than typical malware IoCs.
- File Hashes: N/A (Focus is on content, not executables)
- File Names: Assets within web directories, typically bundled JavaScript files (e.g., `*.js`, `index-*.js`).
- Registry Keys: N/A
- Network Indicators: If tokens are validated, subsequent network traffic to the associated service might be observed (e.g., API calls using the exposed token). (Defanged examples are not applicable without context on the actual tokens found).
- Behavioral Indicators: Discovery of unusual patterns that resemble hardcoded tokens or API keys within web assets during automated scanning.
## Associated Threat Actors
- **Cybercriminals/Opportunistic Actors:** Actors performing automated scans looking for common secrets patterns in exposed web assets, regardless of their affiliation.
## Detection Methods
Detection relies heavily on advanced scanning methods that emulate or analyze client-side code execution pathways.
- **Signature-based detection:** Scanning JS bundles/source code for known regex patterns matching specific types of leaked tokens (e.g., AWS keys, GitHub tokens, etc.).
- **Behavioral detection:** Monitoring web asset retrieval and analysis for static content containing high-entropy strings matching credential formats.
- **Related Tooling:** Novel secrets detection methods built to address the gaps of traditional tooling (as developed by Intruder in the article).
## Mitigation Strategies
- **Prevention Measures:** Implement robust client-side secret scanning (SAST/DAST enhancements) specifically targeting bundled JavaScript files before deployment.
- **Hardening Recommendations:** Never include strictly sensitive, long-lived secrets in client-side code. If interaction with restricted APIs is necessary from the front-end, use a secure back-end proxy layer (e.g., a serverless function) to handle credential exchange.
- **Tool Improvement:** Ensure security scanners (both infrastructure and specialized secrets tools) fully spider application pages and analyze all fetched resources, including dynamically loaded component bundles.
## Related Tools/Techniques
- **Nuclei:** Mentioned as a traditional scanner whose limitations (not analyzing JS files fetched post-initial request) highlight the gap.
- **DAST (Dynamic Application Security Testing):** Generally more capable but often underutilized or misconfigured for comprehensive secrets detection in JS bundles due to cost/complexity.
- **SAST (Static Application Security Testing):** Effective for source code but can miss secrets bundled/injected into compiled JS artifacts in ways that static pattern matching fails to catch.