# A client-side secret scanner that physically can't exfiltrate your code (and why you shouldn't trust mine either)

> Source: <https://dev.to/wrg11/a-client-side-secret-scanner-that-physically-cant-exfiltrate-your-code-and-why-you-shouldnt-1252>
> Published: 2026-05-30 18:49:25+00:00

There's an irony in most "paste your config to check for leaked secrets" web tools: pasting a secret into a random website *is* the leak. You're trusting a server you can't see.

So I built [devguard-scan](https://wrg-11.github.io/devguard-scan/) the other way around — it runs 100% in your browser, zero dependencies, and makes **no network calls at all**.

**Don't take my word for it.** Open DevTools → Network, scan a file, and watch zero requests fire. The source has no `fetch`

, `XMLHttpRequest`

, `WebSocket`

, or `sendBeacon`

— grep it yourself. It can't exfiltrate what it never calls.

**The 10 detection rules** (OpenAI, AWS, GitHub classic + fine-grained PAT, Stripe, Google API, Slack token + webhook, private-key blocks, generic assignments) aren't a weaker JS port — they're the exact regex set from a canonical Python scanner, parity-checked byte-for-byte so the convenience of "in-browser" doesn't cost you detection coverage.

It's a POC, MIT-licensed, and open to rule-requests: [github.com/WRG-11/devguard-scan](https://github.com/WRG-11/devguard-scan)

The broader point: for a security tool, "trust me" isn't good enough. The design should make the safety property *verifiable by the user* — here, an empty Network tab. What other dev tools should be provable rather than promised?