DEV Community

Bren Builds
Bren Builds

Posted on

I scanned 37 sites from Hacker News for leaked secrets. One had 6.

#ai #javascript #security #webdev

Most security tools scan your GitHub repo looking for accidentally committed secrets. That's useful. But it misses something...

What about the secrets that are deployed?

I built a scanner that checks your live site. It downloads your JavaScript bundles and runs regex patterns against them. The same thing an attacker would do if they opened DevTools and clicked View Source.

I pointed it at 37 sites from the Hacker News front page over two days. Mostly indie projects and startups.

The results

One site had 6 real secrets in their production JavaScript:

  • 1 AWS credential
  • 5 API keys (Stripe, SendGrid, and others)

The site launched recently. The founder probably has no idea.

How secrets end up in production JavaScript

This happens more than people think. Here's a common example.

You have an environment variable:

NEXT_PUBLIC_STRIPE_KEY=sk_live_abc123...
Enter fullscreen mode Exit fullscreen mode

Or maybe you're using Vite:

VITE_OPENAI_KEY=sk-abc123...
Enter fullscreen mode Exit fullscreen mode

These frameworks inline environment variables that match certain prefixes into your client bundle at build time. It's documented behavior. But developers forget which keys are public and which are secret.

After the build, your main.js or app.bundle.js contains something like this:

const config = {
  apiKey: "sk_live_abc123realkey",
  region: "us-east-1"
};
Enter fullscreen mode Exit fullscreen mode

Anyone can find it. Open DevTools, go to Sources, search for "sk_live" or "api_key". Done.

The fix isn't in your repo anymore

Here's the problem with repo scanners. You committed a secret six months ago. You realized the mistake and removed it. You rotated the key. Great.

But did you redeploy every environment? Is that old bundle still sitting in a CDN cache somewhere? Is your staging site still running the old build?

Repo scanners check your current code. They don't check what's actually running.

Not every detection is a real problem

I want to be clear about this. The scanner uses pattern matching. It flags things that look like API keys.

Some of those are fine. Firebase client configurations are meant to be public. Stripe publishable keys (starting with pk_) are designed for frontend use. Google Maps API keys are often restricted by domain.

The tool flags patterns worth checking. You decide what's actually a problem.

Try it yourself

The scanner is free. No signup. One click.

https://domainoptic.com/audit

If you want to see what a detection looks like first, scan wirier.com. I built it as a demo target with fake secrets planted in the code.

If you find something on your own site, congrats!

Top comments (0)