Topic starter
04/09/2026 5:27 pm
TL;DR: 12 candidate secret and API-key exposures surfaced across 10 bug bounty programs, with 7 validated by affected programs and 5 closed as informative, according to FireCompass, showing that browser-delivered code can expose signing secrets, internal credentials, and third-party API keys before any backend breach occurs. The real control gap is not detection but deciding what must never be shipped client-side, how it is scoped, and how quickly confirmed exposure is revoked.
Editorial analysis by NHI Mgmt Group, based on content published by FireCompass: “Shipped to the Browser: How FireCompass’s Agentic AI Penetration Testing Found API Keys and Signing Secrets Hardcoded Into Client-Side Code Across Ten Independent Programs”.
Key questions
Q: What breaks when a signing secret is shipped to browser-delivered code?
A: The authentication boundary breaks, because the browser is no longer a safe place to keep a secret that signs tokens or requests.
Q: Why do exposed API keys and signing secrets create different levels of risk?
A: An exposed API key may mainly allow quota abuse or limited third-party access, while a signing secret can let an attacker forge identities and generate new valid requests.
Q: How should teams decide whether a client-side secret exposure is a real incident?
A: Treat it as real once the recovered value is live and can be used in the intended workflow, even if the original finding came from pattern matching.
Practitioner guidance
- Remove server-side credentials from client-delivered assets Keep signing keys, internal application secrets, and server-to-server tokens out of JavaScript bundles, source maps, global objects, and config responses.
- Scope any unavoidable third-party key to the browser context Use referrer, IP, quota, and feature-specific restrictions so a leaked key cannot be reused outside the intended page or domain.
- Treat confirmed exposure as a revocation event Rotate or revoke any secret once it is verified in shipped code, even if the report is later classed as informative or duplicate.
Bottom line: Secrets shipped to browsers are exposed by design, not by accident, because anything delivered client-side can be inspected and reused.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/09/2026 5:27 pm
Client-delivered secrets are an identity governance failure, not just a code quality defect. If a credential can authenticate a caller, then it has an identity lifecycle, even if engineering teams treat it as a build-time convenience. The browser boundary does not dilute that risk, it exposes it. Practitioners should treat frontend distribution as part of secret governance, with the same ownership, scope, and revocation discipline they apply to backend credentials.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should organisations rotate a secret found in frontend code?
A: Rotate immediately after confirmation, not after a full postmortem. A credential embedded in shipped code is already exposed to anyone who loads the page, so waiting for routine change windows extends the blast radius unnecessarily. If the value authorises production access, revocation should be treated as urgent lifecycle hygiene.
👉 Read our full editorial: Client-delivered code turns secret handling into an exposure problem