Notifications
Clear all
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.
NHIMG editorial — based on content published by FireCompass: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
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 security teams decide what can safely be shipped to the browser?
A: Only information that can be treated as public should ever reach the browser.
Practitioner guidance
- Ban server-side secrets from client artifacts Reject releases that contain signing keys, internal application secrets, or server-to-server tokens in JavaScript bundles, source maps, or config responses.
- Scope every browser-exposed API key tightly Apply referrer, IP, quota, and usage restrictions to any third-party key that must ship client-side.
- Treat confirmed exposure as compromise until rotation completes Once a live secret is confirmed in client-delivered code, rotate it immediately and verify downstream revocation.
What's in the full report
FireCompass’s full analysis covers the operational detail this post intentionally leaves for the source:
- Representative mechanics for each exposure pattern, including how the secret appeared in bundles, source maps, or config responses.
- The detect, validate, controlled-exploit sequence used to prove whether each candidate secret was live and usable.
- Severity and disposition context for the seven validated findings versus the five closed informative reports.
- How FireCompass grouped the findings into recurring mechanisms across different industry programs.
👉 Read FireCompass’s analysis of secret and API-key exposure in browser-delivered code →
Client-delivered secrets: what IAM and app teams need to change?
Explore further
04/09/2026 5:27 pm
Client-delivered secret exposure is a non-human identity governance failure. When a signing secret or internal credential is shipped to the browser, the issue is not merely leakage but uncontrolled delegation to an untrusted execution environment. That makes the exposed value a non-human identity that has escaped its intended lifecycle boundary. IAM and application teams should treat browser-delivered secrets as a governance defect, not a post-release nuisance.
A question worth separating out:
Q: How do teams know whether a secret exposure is operationally exploitable?
A: They should validate whether the recovered value is live, accepted by the target system, and capable of producing a bounded real-world effect. If a single authenticated request, token mint, or billable call succeeds, the exposure is operational, even if the final report later classifies it as informative.
👉 Read our full editorial: Client-delivered code turns secret handling into an exposure problem
