SourceDetector turns browsing into an audit: it collects source maps, stores them locally and flags key like strings

The problem is what a site ships, not what it hides

Source Detector is a Chrome extension for discovering source maps, collecting client side artifacts and detecting potential secret leakage in web assets. The repository description compresses the value proposition into a sentence: discover source maps, inspect client-side assets, catch risky leaks faster.

The threat model is specific. A JavaScript bundle shipped to every visitor is public by definition, and a source map makes it readable and structured. If a developer left an API key, an internal endpoint or a service credential in that bundle, the credential is not hidden, it is merely unformatted. This extension is built to make that class of mistake visible to a person who is already browsing the target site.

The stated audience is security researchers, bug bounty hunters, front end engineers and developers auditing client-side exposure. That last group is the interesting one, because the tool is useful to the people who write the code as well as to the people who hunt for it.

The workflow described in the documentation is five steps: visit a website in Chrome, let Source Detector watch the relevant client-side assets and source map references, keep the findings locally on your device, let the built in and custom rules scan the collected assets for risky patterns, then review the evidence in the popup or the explorer and export artifacts when needed.

That last step is what separates it from a bookmarklet or a manual inspection. The extension does the collecting while you browse, so coverage is a function of where you went rather than of how carefully you looked.

Local first storage means no account and no backend

The privacy section is the part of this project that matters most for an adopter, and the claims are concrete.

Source Detector is designed to work locally on your device. The documentation lists local-first storage for collected artifacts and settings, no account required, and no remote backend required for core functionality. Permissions are used for source map discovery, local storage and analysis workflows.

For a security tool, a local-only design is not a feature detail, it is the trust model. An extension that uploads the assets it finds to a server is a server with a copy of your targets. One that keeps everything in the browser profile cannot leak what it collects, cannot be used as an exfiltration channel, and does not need to be trusted with anything.

The trade is that you own the data. There is no shared workspace, no cross device sync and no server side correlation of findings across a campaign. A researcher working through a list of twenty subdomains does that work in one profile and exports ZIPs when they want to review or hand the files over.

The privacy policy is published both online and as a repository file, PRIVACY.md, and the README links it directly. There is also a .ga4-website-measurement-id file at the repository root, which indicates that the project's own website, rather than the extension, carries analytics measurement.

Running it from source takes one command and an unpacked load

The Chrome Web Store listing is the normal install path, and the extension id is published in the overview. For development, the documented procedure is to clone the repository, install dependencies, and start the watch build:

npm run dev:chrome

The build script is a watch mode over a TypeScript build script, so edits to the source are recompiled as you work. Loading it into Chrome then takes four steps: open chrome://extensions, enable Developer mode, click Load unpacked and select the dist/chrome directory.

The dist/chrome path is also what the packaged build produces, so the same directory works for both development and a manual load of a release artefact.

The package scripts show how many targets are in play. There is a dev script and a build script for chrome, a dev:firefox and build:firefox pair that run the same build script with a different browser flag, and a build:all script that runs the Chrome build followed by the Firefox build. A single TypeScript build script under scripts/ drives all of them with a browser parameter, which is a small design decision that keeps the two targets from drifting.

Testing is split the same way. Unit tests run with the Node test runner over the test files in src, and end to end tests run under Playwright.

For a contributor, the practical sequence is npm install, npm run dev:chrome, then load the unpacked extension and browse a target.

Releases are cut by a tag and the zip is verified before upload

The release process is documented precisely enough to script against, which is unusual for a small extension.

A release is triggered by pushing a semver tag matching v*.*.*, for example v1.3.1, or by running the Release Extension workflow manually from the Actions interface. The workflow file is .github/workflows/release.yml, and it does four things: it runs npm ci, it runs the Chrome build, it verifies that dist/source-detector-chrome.zip exists, and it creates or updates a GitHub Release with the zip uploaded.

The build command itself is a single line:

npm run build:chrome

and the two artefacts it produces are the unpacked extension in dist/chrome and the packed zip at dist/source-detector-chrome.zip.

The verification step between build and upload is the part that makes this trustworthy. A release cannot go out with a missing or misnamed artefact, because the workflow checks for it first.

The published tags are v1.4.1 and v1.4.0, both on 2026-03-19, and v1.3.3 on 2026-03-10. Two releases on the same day, with a ten day gap before them, suggests a tight iteration loop around the March 2026 work.

The repository also carries operational paperwork that a project of this size normally lacks: E2E_TEST_REPORT.md, TEST_REPORT.md, TEST_STRATEGY.md and LAUNCH_CHECKLIST.md, plus a docs/ directory with a Pages guide, a growth roadmap, an FAQ and an assets plan.

The rules directory is where the detection logic lives

Detection is split into built in rules and custom rules, and both can be managed from Settings. The overview lists what the scanning step does: built in and custom rules scan collected assets for risky patterns.

The repository layout puts this in a rules/ directory at the top level, separate from src/. That separation is meaningful for a scanner whose detection logic is the product. The rules are data that a user can extend, and the scanning engine in src/ is the mechanism that applies them.

The output side is described as a unified Source Explorer for domains, pages, versions and code evidence. The word versions there points at something worth understanding: the explorer appears to keep multiple observations of the same page, so a site that ships a new bundle can be compared against its previous version rather than simply overwriting what was seen. The overview does not describe the comparison behaviour, so treat that as an inference from the vocabulary rather than a documented feature.

The popup shows risk summaries with drill down evidence. That distinction is the design: the summary tells you whether a page is worth attention, and the evidence is one click away so you can see the actual matched string rather than a verdict.

For a bug bounty workflow, the ZIP export for selected versions or domain batches is the other half of the tool. It turns a browsing session into a deliverable you can attach to a report.

The dependency list explains the architecture

Reading the dependencies in package.json tells you more about how Source Detector works than the prose does.

The package is marked private, so it is never published to npm; it is an application that happens to be built with Node tooling. Its version is 1.4.1, matching the newest tag.

dexie is the storage layer, an IndexedDB wrapper, which confirms the local-first claim at the implementation level. jszip is there for the ZIP export. source-map-js is the source map parser, which is what lets the extension read and show original sources from a discovered map. crypto-js suggests hashing work, plausibly for fingerprinting or deduplicating collected assets. webextension-polyfill provides a consistent API across browsers, which matters for the Firefox target. React with the MUI component suite and react-router-dom build the popup and explorer interfaces, and @mui/x-tree-view handles the tree of domains and pages.

The Playwright end to end suite and the node test runner split, together with a webpack style esbuild based build script under scripts/build.ts, point at a project with real engineering discipline for its size.

One dependency detail is worth flagging for security reviewers. The extension itself inspects other sites' assets for credentials, so its own permission footprint and supply chain deserve the same scrutiny it applies elsewhere: the repository pins exact versions in package-lock.json, and the release workflow uses npm ci rather than npm install, which is the right choice because it installs from the lockfile.

Editorial conclusion

Use SourceDetector if your work involves auditing what a site ships to the browser, because it turns passive browsing into a local archive you can grep for leaked keys and export as ZIP. Do not rely on it as a scanner that can find vulnerabilities you have not visited, since it observes pages you open and does not crawl. Before installing it in an environment where browser extensions are restricted, read the privacy policy and confirm the local storage model, then load the unpacked build from dist/chrome in a browser profile you do not mind contaminating with third party assets.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SunHuawei/SourceDetector on GitHub