Service-account JSON in the bundle — Firebase admin via the browser
Embedded service-account JSON grants administrative access to Firebase/Cloud resources. KeyDrift refines this pattern specifically. Free scan.
Firebase tutorials tell you to keep service-account JSON server-side. Bundles occasionally disagree — and when they win, visitors receive administrative credentials formatted as helpful JSON.
Structure, refinement logic, response.
What a Google/Firebase service-account private key is
Service-account JSON embeds a PEM private key plus metadata; Firebase Admin authenticates with exactly this blob.
{ "type": "service_account", "private_key": "-----BEGIN PRIVATE KEY-----\nFAKE..." }The prefix is the claim: scanners and attackers alike identify the format before they know anything else about it, which is why recognition starts at the first characters rather than the last.
What it grants
Administrative by definition:
- Full Firebase project control (Auth users, Firestore, Storage rules).
- GCP resource reach per role bindings.
How it ends up in a bundle
Three arrival routes cover nearly every case we see:
- Admin SDK demos imported client-side for “quick scripts”.
- Config dumps accidentally exported to public modules.
Does it belong in a browser?
Server-only, vault-preferred; never bundled under any framing.
Rotate it
IAM → service account → keys: revoke exposed, mint replacement, redeploy admins.
Find it in seconds
Open DevTools on the deployed site and search the built assets for BEGIN PRIVATE KEY. If the search hits, the credential shipped; if it does not, check the chunks loaded on authenticated or interactive views, not just the landing page — the calling code often sits behind a route.
Manual searching proves one page on one day. KeyDrift fetches the deployment the way a browser would, follows chunks named only in route manifests, reads streamed hydration payloads, and classifies what it finds — secret, or public-by-design — so an anon key never shows up dressed as an emergency.
Make sure it stays gone
One more thing worth knowing before you close the tab: fixing this once does not end the story. Agents imitate whatever pattern is already in the repo, templates carry their own defaults, and the next feature request can reintroduce the same shape of code. Continuous monitoring re-scans every deploy and alerts only on change — new, regressed, resolved — so the comeback attempt is a notification instead of a quarter-end surprise.
Why scanners refine this pattern
Generic PEM rules fire on any private key; KeyDrift upgrades labels when JSON context (private_key/service_account/firebase) surrounds it — precision that routes you to Firebase-specific rotation rather than generic advice.
Why this keeps happening industry-wide
Zoom out and the pattern is bigger than one repo. AI-assisted output has outgrown review capacity everywhere at once, which means thousands of teams are making the same reasonable-looking tradeoffs in the same week. Nobody using modern tooling is uniquely exposed. The failure mode documented above is the modal outcome of velocity without verification, not evidence of carelessness.
How KeyDrift reports this exact finding
Report anatomy matters during incidents, so it is worth reading once calmly: masked string (never the live value — it ceases to exist outside the detection engine), salted fingerprint (trackable within your workspace, useless to strangers), chunk path (your starting point for a "git log -S" hunt), disposition (secret versus public-by-design), confidence (matches below 0.5 never reach the page at all).
Manual check, step by step
The full manual drill, for readers who want zero dependence on any tool: open the deployed site in a private window; launch DevTools → Sources; use Search-all-files (Ctrl/Cmd+Shift+F) for BEGIN PRIVATE KEY; then repeat for the other marker families — eyJ, sk_live_, sk-proj-, AKIA, postgres, BEGIN PRIVATE KEY. Decode anything JWT-shaped before reacting, and classify public-by-design formats as expected guests rather than intruders.
Close the loop with monitoring
If you take one operational step from this page, make it this: put the URL under continuous monitoring (free tier covers one project daily). The first scan tells you whether you have a problem today; the schedule tells you whether the problem comes back next month after someone re-adds the convenient line.
Common questions
App Engine default certs too?
Similar handling when detected structurally; same response order applies.
Rotation invalidates active sessions?
Admin SDK auth uses these keys continuously — expect brief reauth churn post-rotation.
Run a free scan at keydrift.dev/scan — paste a URL or the bundle source itself, no account. Findings arrive masked, with the exact chunk they live in.