Show HN: KeyLeak Detector – Scan websites for exposed API keys and secrets
github.comI built this after seeing multiple teams accidentally ship API keys in their frontend code.
The problem: Modern web development moves fast. You're vibe-coding, shipping features, and suddenly your AWS keys are sitting in a <script> tag visible to anyone who opens DevTools. I've personally witnessed this happen to at least 3-4 production apps in the past year alone.
KeyLeak Detector runs through your site (headless browser + network interception) and checks for 50+ types of leaked secrets: AWS/Google keys, Stripe tokens, database connection strings, LLM API keys (OpenAI, Claude, etc.), JWT tokens, and more.
It's not perfect, there are false positives but it's caught real issues in my own projects. Think of it as a quick sanity check before you ship.
Use case: Run it on staging before deploying, or audit your existing sites. Takes ~30 seconds per page.
MIT licensed, for authorized testing only.
> I've personally witnessed this happen to at least 3-4 production apps in the past year alone.
There is something seriously wrong in your organization when that's a repeating pattern. Secrets don't just accidentally make their way into the frontend unless the way you manage secrets is fatally flawed. Offensive security tools are great for finding issues by playing the role of an adversary, but they are not the solution to such an already known grave, fundamental, organizational problem.
Well, when i meant "personally" not in the app I manage. I have a quirk of checking sites to understand what they are using and how they are using and have stumbled upon sites with exposed Gemini, Google Maps, OpenAI keys etc.
https://news.ycombinator.com/item?id=45741569 - It was also partly inspired by this as I have seen legacy sites making these mistakes quite often.
With all the vibe coded apps that are getting launched or were launched early, there are enough holes to plug. This is just an attempt to help individuals or orgs to ensure they are not exposed. Just pushed it out what I had in mind based on my experience.
And I agree with you that an adversary approach won't work if we can't fix the underlying problem but the world has changed with enough vibe coded apps that are getting shipped everyday and very little of them care or know about security.
You're not wrong. How are these things passing review? Are prs too big and should be broken down into more manageable pieces? Or people just yolo to prod?
Secrets exposure is just one of your problems if there are not processes in place to catch this upstream.
That being said, this is a show hn and we should be gentler with criticism. The tool is still very useful even for mature organizations to identify blind spots and process failures.
Yep, Github does a wonderful job flagging secrets most times but irrespective of that this is happening in some sites. This was built out of personal curiosity and I had put it out for public because I myself was not aware if this will be actually useful and if so in what form. People do YOLO to prod, we have more kids building AI wrappers than I can count, and somewhere in that chaos secrets slip through the cracks.
Ideally I would have loved this to be a chrome plugin or part of the CI/CD pipeline or put it out as an adversary agent for all of these new vibe coded apps but don't think I'm that vested into the idea yet. Thanks for being gentle :)
I don't mean to criticize the tool itself.
How does this compare to https://github.com/gitleaks/gitleaks ?
Gitleaks is too good to be compared to this, the only areas where keyleak is comparable is it does runtime detection where sometimes your build process injects secrets via env vars into the bundle or any of your responses expose a config file or secrets.