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

Every browser tab runs code the vendor chose to send to it, and everything in that code is visible to whoever opens developer tools, reads a source map, or decompiles the bundle. A recurring and often underestimated class of exposure is what happens when that shipped code, or a config response it calls, carries something that was never meant to leave the server: a third-party API key, a signing secret used to authenticate requests, or an internal application credential. Unlike a backend vulnerability, nothing needs to be breached to find these, they are delivered to anyone who loads the page.

Across a series of independent bug bounty assessments spanning financial services and payments, consumer goods, food and beverage, semiconductor technology, internet and gaming conglomerates, media and publishing, consumer lending, and insurance, FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs surfaced 12 candidate secret and API-key exposure findings across 10 distinct programs. Seven of those findings, spanning 7 of those programs, were validated by the affected programs as genuine issues, triaged, placed into pending review, newly opened, or confirmed as duplicates of an already-known valid report, rather than closed as informative. Those seven validated findings split across two consecutive quarters: three surfaced in 2026 Q2 and four in early Q3.

A note on the 5 findings closed informative: being closed informative does not mean the underlying exposure was inaccurate. In fact, this excluded set includes the sample’s only critical-severity finding, a published source map that exposed a hardcoded token together with the application’s full frontend source, and one of its three high-severity findings. Being closed informative here most often reflects a program’s risk tolerance for a specific class of secret (frequently a third-party API key with its own usage quota, rather than a credential that grants direct account access), not a determination that the reported behavior was wrong or unreproducible.

Because that distinction matters, this article covers all 12 candidates the agent surfaced, not only the seven the affected programs acted on. Each finding below is grouped by mechanism, with its actual status and severity noted, because the underlying mistake is identical regardless of how a given program chose to classify it.

To protect the affected organizations, all identifying information, including company names, domains, endpoints, request paths, and HackerOne report identifiers, has been removed throughout this article. Each finding is referenced only by industry and vulnerability mechanics; third-party platform vendors are named only where naming them does not identify the client program itself. Technical descriptions below are representative compositions of each finding’s mechanics, written to convey how the issue works and was proven without disclosing exploit-ready specifics.

The Twelve Findings

The 7 findings placed into pending review, triaged, newly opened, or confirmed as duplicates of an already-known valid report are listed first; the 5 findings closed informative follow.

The Client-Side Trust Gap Behind Every Secret Leak

In every one of these 12 findings, the team that generated the secret made the same implicit assumption: that because a value wasn’t shown anywhere in the user interface, it wasn’t retrievable by the client. That assumption breaks the moment the secret is embedded in a JS bundle, a source map, a global window object, or a config response, because all of those are, by definition, sent to the browser, and anything sent to the browser can be read by whoever loads the page.

The flow that recurred, with only the type of secret changing, looked like this:

From Anomaly to Proof: A Three-Stage Validation Model

A secret-scanning tool can flag a string that looks key-shaped. It cannot, on its own, tell a defender whether that string is a live production credential, a decommissioned test value, or a placeholder, and it almost never proves what the credential actually unlocks. Across all 12 candidates, FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs went a step further, running the same three-stage discipline every time:

That third stage, controlled exploitation, is what separates a pattern match from an evidence-backed finding, and is the stage a static secret scanner cannot perform on its own.

How the Pattern Played Out Across Four Mechanisms

Correlating the 12 candidates after the fact grouped them into four recurring mechanisms, each shipping a different kind of secret to the browser.

Pattern 1: Unrestricted Third-Party API Keys Exposed in Frontend Code (3 findings)

The most repeated mechanism in the sample: a Google Maps Platform key intended only for the program’s own frontend, shipped without any referrer, IP, or quota restriction, at a payments-technology provider, a consumer-goods distributor, and a money-transfer platform:

Bank configuration key disclosure (Financial Services / Payments Technology, Unrated, Informative): a bank-configuration endpoint returned a live, unrestricted Google Maps Platform key intended only for internal use by the banking frontend, to any caller who queried it.

Distributor locator key exposure (Consumer Goods / Personal Care, Unrated, Informative): a public distributor-finder page shipped an unrestricted Google Maps Platform key directly in its frontend code, with no referrer restriction applied.

Frontend key exposure, two independent instances (Financial Services / Money Transfer, High, Duplicate): a money-transfer platform’s frontend shipped an unrestricted Google Maps Platform key in its JavaScript on two separate, independently surfaced occasions. The second instance of the same unrestricted-key exposure on the same platform’s frontend code was confirmed as a duplicate of an already-known valid report, and rated more severely than the first.

Pattern 2: Hardcoded Signing Secrets Enable Forged Authentication (4 findings)

A more severe variant of the same mistake: instead of a third-party API key, the exposed secret was the signing key an API used to trust its own tokens or requests, recurring at a food and beverage manufacturer, a semiconductor technology firm, an internet and gaming conglomerate, and a media publisher:

Source map token and source disclosure (Food & Beverage / CPG, Critical, Informative): a published source map for a warehouse-management-system integration exposed the full, unminified frontend source together with a hardcoded API token in plaintext.

CMS signing secret exposure (Semiconductor / Technology Hardware, Medium, Pending Review): a public JavaScript bundle supporting a CMS integration contained that CMS API’s HS256 JWT signing secret in plaintext.

Telemetry signing secret exposure (Internet / E-Commerce & Gaming Conglomerate, High, Informative): a public JavaScript bundle for an internal telemetry service exposed the signing secret used to authenticate events sent to it.

Data-segment signing secret exposure (Media / Publishing, Medium, Triaged): a public JavaScript bundle exposed the HMAC signing secret used to authorize a data-segmentation API.

Pattern 3: Internal Application Secrets Shipped to the Browser, Recurring Within One Organization (2 findings)

The same organization behind the telemetry signing-secret finding above produced this pattern too, in two unrelated internal products:

Internal configuration console secret (Internet / E-Commerce & Gaming Conglomerate, Medium, Duplicate): an internal content-configuration console shipped its backend appSecret directly inside a client-side global JavaScript object.

Internal chat-integration webhook token (Internet / E-Commerce & Gaming Conglomerate, Medium, Informative): an internal enterprise chat integration shipped its outbound webhook token hardcoded inside a public JS bundle.

Pattern 4: Over-Scoped Third-Party Content and Search Delivery Tokens (3 findings)

The fourth mechanism didn’t involve a signing key or a first-party secret at all, it involved a legitimate, intentionally client-side third-party token that was scoped too broadly, recurring at a consumer lender, an insurer, and a gaming publisher:

Over-scoped CMS delivery token, marketplace content (Fintech / Consumer Lending, Unrated, Duplicate): a headless CMS delivery token embedded in a customer portal returned non-public marketplace content when queried directly against the vendor’s API, beyond what any page on the site rendered.

Over-scoped search platform token (Financial Services / Insurance & Retirement, High, Duplicate): an enterprise search platform’s bearer token, embedded to power the site’s search experience, granted access to the organization’s full indexed document set when queried directly.

Over-scoped CMS delivery token, promotional codes (Gaming / Interactive Entertainment, Medium, New): the same class of headless CMS delivery token, on an unrelated program, exposed unreleased promotional voucher codes when queried directly against the vendor’s API.

Why This Matters

Severity Reflects Risk Tolerance, Not Just Technical Impact: the single critical-rated finding and one of the three high-rated findings in this sample were both closed informative, while the validated set skews medium, showing that whether a program treats a given secret type as actionable often tracks its own risk tolerance for that class of exposure more than the raw severity rating attached to it.

No Backend Compromise Required: every finding in this sample was reachable by reading code or responses the program itself served to any visitor, no authentication bypass, no injection, and no backend access was needed to obtain the secret.

Cross-Industry, Cross-Mechanism Recurrence: the same category of mistake, a secret meant to stay server-side or build-time instead shipped to the browser, reproduced independently across payments, consumer goods, food and beverage, semiconductor technology, internet and gaming, media, consumer lending, insurance, and gaming publishing.

Proven Impact, Not Theoretical Risk: every candidate was carried through a single live validation step against the real API or backend it unlocked, so each finding shipped with direct evidence the secret worked, not a static pattern match against a string that merely looked like a key.

Root Cause

Every one of these 12 findings shares one architectural root cause: the team that generated the secret treated “not displayed anywhere in the user interface” as equivalent to “not retrievable by the client”, two very different statements that only look alike until someone opens developer tools or reads a source map. Signing secrets, application credentials, and third-party API keys were all issued for a legitimate purpose; the mistake was never separating the code path that runs on a server the team controls from the code path that ships to a browser the team does not.

Remediation and Key Lessons for Organizations

Never Ship Secrets Meant for Server-to-Server Calls to the Browser: any credential that authenticates the backend to another service, a signing key, an application secret, an unrestricted third-party API key, belongs behind a server-side proxy, never inside client-delivered code.

Scope and Restrict Every Third-Party API Key by Referrer, IP, and Quota: a key that must ship client-side should still be useless outside the program’s own domains, with a quota ceiling that limits the damage of extraction.

Rotate Any Secret Found in Shipped Code Immediately: assume a secret is compromised the moment it is confirmed reachable, regardless of how a given report is ultimately classified.

Strip Source Maps From Production Deploys, or Gate Them Behind Authentication: a source map turns a minified bundle back into full, readable source, including anything hardcoded inside it.

Scope Third-Party Delivery and Search Tokens to Exactly the Published Content They Need to Render: a token that renders one page should not be able to enumerate an entire vendor-hosted content model.

Correlate Findings Across Products, Not Just Programs: the same organization produced two of these findings in unrelated internal tools, a shared engineering habit, once introduced, tends to recur wherever a team reaches for the same shortcut.

Lessons Learned

Secrets shipped to the browser are not an exotic mistake, they are what happens when a team that correctly protects its backend never asks whether the same protection extends to everything the frontend calls or bundles. Seeing the same category of exposure recur across ten independent programs and at least four distinct secret types, third-party API keys, signing secrets, internal application credentials, and over-scoped delivery tokens, is a strong signal that this is a systemic blind spot in how frontend builds are reviewed, not a one-off oversight by any single team.

It is worth being equally disciplined about what does not belong in the validated count, and equally fair about what it means. Of the 12 candidates the agent surfaced, 5 were closed informative, including the sample’s most severe finding. That exclusion from the validated count is about a program’s risk tolerance for a given secret type, not about whether the underlying exposure was real; every one of those 5 findings was independently confirmed live during validation, the same as the 7 the programs acted on.

How FireCompass’s Agentic AI Penetration Testing Identified and Exploited These Bugs

Across all four patterns, the same autonomous sequence produced every finding: scan shipped code, config responses, and source maps for key-shaped or secret-shaped material, validate that the recovered value authenticates a real request against the live backend or third-party API, then perform a single, bounded action, one billable call, one forged token used once, one enumeration query, to prove impact before a human ever saw the report. No step required a human operator to manually extract or test the secret, and no step exhausted a quota, forged a token at scale, or left lasting effect on any real account or system.

The advantages this demonstrates for an agentic platform over manual secret-hunting:

Continuous, Unscoped Coverage: the same discipline scans every shipped bundle, source map, and config response autonomously, not a manual sample, which is how the identical key-shaped mistake got caught independently across ten unrelated programs.

Evidence-Backed Findings, Not Guesses: every candidate secret is validated live against the real API and carried through a single controlled action before being reported, so defenders receive proof it works instead of a pattern-match flag.

Consistent Methodology at Scale: the same detect/validate/exploit sequence applies identically whether the secret is a Maps key, a signing secret, or a delivery token, producing comparable, correlatable results across an entire program portfolio.

Safe by Construction: every exploitation step is a single, bounded action, one billable call, one forged token, one enumeration query, with no quota exhaustion or lasting side effect.

Faster Time to Validated Finding: extraction, live validation, and safe proof-of-impact happen autonomously, freeing human researchers to focus on the judgment calls the agent flags rather than manually testing every key-shaped string a scanner surfaces.

For defenders, the broader takeaway stands regardless of platform: any secret that reaches client-delivered code should be treated as public the moment it ships, and reviewed accordingly before release, not after a researcher, or an attacker, finds it first.

Related reading: how FireCompass AI Agent ranked in HackerOne’s top 3, the 2026 guide to web application penetration testing, and how agentic AI pentesting compares to human pentesting in 2026.