Secret Detection in Source Code: How Vexta Finds Leaked Keys

Secret detection in source code is the process of scanning code and its assets for hardcoded credentials, such as API keys, tokens, and passwords, that were committed or shipped by accident. Vexta runs this as part of its static analysis, pairing regex-based secret detection with dangerous function pattern matching and JavaScript endpoint extraction, so a hunter does not have to grep through a codebase or a bundled JS file by hand.

The problem: secrets end up in the wrong places constantly

A hardcoded API key in a config file that got committed, a password left in a comment during debugging, a token pasted into a client-side JavaScript bundle because it was faster than setting up a backend proxy: these happen in real codebases more often than most teams would like to admit. Once a secret ships, whether in a public repo, a client-side bundle served to every visitor, or an internal codebase in scope for an engagement, it is a finding waiting to be noticed.

The problem for a hunter or an internal security team is coverage. Reading through every file and every minified JavaScript bundle by eye does not scale, and a missed secret is a missed finding, or worse, a live credential nobody rotated because nobody knew it was exposed.

What does Vexta's SAST module actually check for?

Vexta's static analysis runs regex-based secret detection to catch patterns that look like API keys, tokens, and passwords wherever they appear in accessible code. Alongside that, it flags dangerous function patterns, calls to constructs like `eval()`, `exec()`, `system()`, and `innerHTML`, that are common sources of injection and code-execution vulnerabilities when they process untrusted input.

The two checks target different risks with the same pass: secret detection is about what should never have been committed, and dangerous function detection is about code paths that are structurally risky regardless of whether a specific exploit has been demonstrated yet.

How does secret detection work on client-side JavaScript?

A meaningful share of leaked secrets show up in the JavaScript actually shipped to a browser, not in a server-side repository a hunter can browse directly. Vexta's JavaScript recon component extracts endpoints and looks for hardcoded secrets in that client-side code as part of normal reconnaissance, meaning the same secret-hunting logic applies to what a target actually serves to visitors, not just to a codebase a hunter happens to have access to.

That matters because a bundled JavaScript file is often the only code artifact a hunter working from the outside can actually see. Extracting endpoints from it also surfaces API routes and internal paths that would otherwise stay hidden behind a minified bundle, widening what recon actually covers before any secret-specific check runs.

What happens to a secret once Vexta finds one?

A discovered credential does not just sit in a findings list. Vexta's credential engine accepts credentials surfaced from SAST, JavaScript analysis, GitHub dorking, and configuration leaks, then tests them against services discovered elsewhere in the scan. A successful authentication gets written back into Vexta's attack graph as an `authenticates_to` edge connecting the credential to the service it accessed.

That connection is what turns a leaked secret from a standalone finding into part of a larger attack path. A password found in a config comment might look minor by itself; a password that Vexta confirms authenticates to an exposed admin service is a very different finding, and the graph is what shows that link automatically rather than leaving a hunter to test each credential by hand.

Where this fits in a scan

Secret and dangerous-function detection run as part of Vexta's broader reconnaissance and static analysis pass, alongside software composition analysis and the rest of recon. None of it depends on an AI key; it is regex and pattern-based detection that runs the same way whether AI triage is enabled or not.

For an authorized engagement, confirming a leaked credential still works means demonstrating real impact within scope, not just flagging that a string looked like a key. Feature availability across plans may vary; see the pricing page for specifics.

Key takeaways

The short version of what Vexta's secret detection covers: