DEV Community

Henrique Yuri
Henrique Yuri

Posted on

Five other projects have the exact same fake API key in their tests

#security #opensource #testing #devops

GitHub flagged a Google API key in my repository. It was a fixture I had made up — sequential filler after the AIza prefix, never a real credential.

What I didn't expect was the sidebar on the alert page. Under Public leaks, GitHub lists every other public repository where it has seen the same string:

…/chat/tests/test_pii_detector.py
…/scanner/core/scanCode.test.ts
…/extensions/secret-guard/redact.test.js
…/scanner/src/diagnostics/redact.test.go
…/internal/cleaner/leakscanner_test.go
Enter fullscreen mode Exit fullscreen mode

Five projects. Python, TypeScript, JavaScript, Go. Different authors, different years, different ecosystems.

All of them secret detectors. All of them with my "invented" key in their test suite.

It was never invented

I wrote AIzaSyA1234567890abcdefghijklmnopqrstuv thinking I had made it up. What I had actually done was reconstruct the most obvious possible fixture: take the documented prefix, fill the remaining 35 characters with the alphabet and the digits in order. Anyone writing a Google API key rule reaches for the same shape, because it is the shape the format forces.

Given a fixed prefix and a fixed length, the space of lazy values is tiny. We all landed on the same one.

There is a nice example of this in AWS's own docs: AKIAIOSFODNN7EXAMPLE. That one is deliberate — Amazon publishes it so people have a safe value to paste. The interesting case is the accidental convergence, where nobody coordinated and everybody agreed anyway.

Why this is a real problem and not a fun fact

Scanners cannot tell. A string is a credential shape or it isn't. AIzaSy plus 35 valid characters matches, and the scanner has no way to know that this particular one has been in five test suites since 2021. So it fires. Correctly, by its own rules.

Which means every one of those repositories has, or had, an open alert like mine. Five maintainers, at minimum, have triaged this exact false positive. Probably far more — the public-leaks list only shows repositories GitHub has indexed and surfaced.

And the failure mode is asymmetric. If you assume it's fake and you're right, nothing happens. If you assume it's fake and you're wrong, you've just dismissed a live credential because it "looked like a test value". The convergence trains exactly the wrong reflex.

What I changed

Not the values — they still need to be realistic, because a fixture that doesn't match the pattern proves nothing. I changed where they exist:

const ex = (...parts) => parts.join("");

// The matcher receives the identical string. The file does not contain it.
example: ex("AIza", "SyA1234567890abcdefghijklmnopqrstuv")
Enter fullscreen mode Exit fullscreen mode

Then made it a build failure rather than a habit:

const CREDENTIAL_SHAPED = new RegExp([
  "ghp_[A-Za-z0-9]{36}", "AKIA[0-9A-Z]{16}", "AIza[0-9A-Za-z_-]{35}",
  "sk_live_[0-9a-zA-Z]{24}", "xox[baprs]-[0-9]{12}", "hf_[A-Za-z0-9]{34}",
  "\\d{9}:[A-Za-z0-9_-]{35}", "eyJ[A-Za-z0-9_-]{10,}\\.eyJ"
].join("|"));
Enter fullscreen mode Exit fullscreen mode

A reader pointed out I had scoped that too narrowly — it covered source files but not documentation, which is backwards, since a README is exactly where a credential-shaped string gets pasted without thinking. It covers docs now.

If you maintain anything that detects secrets

Three things worth checking, and none of them takes long:

  1. Do whole token literals appear anywhere in your source? Including the README, the docs site, and the store listing.
  2. Would a new contributor know not to add one? If the answer is "they'd know because everyone knows", you don't have a convention, you have a coincidence waiting to end.
  3. Can your build fail on it? Twenty lines. It is the only version of this that survives you.

And if you get an alert for a value you're sure is fake: check the public-leaks list before you close it. Mine turned four other people's test files into the evidence.

Context: I was building LeakGuard, which checks text for credentials and personal data before you paste it into an AI chat — 50 rules, 36 providers, entirely in your browser, nothing uploaded. The irony of it being blocked for containing secrets has not been lost on anyone. Source, MIT.

Top comments (0)