What you can detect
This review method can help you detect whether a browser-visible key is acting like ordinary publishable configuration, a narrowly scoped integration credential, or a stronger signal that the frontend may be carrying more authority than it should. It also helps you distinguish live operational use from dead code, copied examples, or token-like strings with little standalone meaning.
Signals to look for
- Runtime participation: the key appears in live fetch, XHR, or SDK initialization during a reproducible page action.
- Sensitive flow context: the surrounding request touches uploads, AI calls, billing-related actions, exports, or user data handling.
- Restriction clues: the key seems bound to one origin, one product flow, one tenant, or one service family rather than broad account behavior.
- Consequence clues: the browser can trigger actions that appear to create cost, invoke provider operations, or widen access beyond simple identification.
- Cross-asset consistency: the same key or pattern appears across live requests and current assets, which makes stale residue less likely.
How to verify
1. Classify where the key appears
A key embedded in a bootstrap object, a key passed to an SDK, and a key attached to a direct network request are not the same level of evidence. Start by asking where the browser actually exposes it and whether the exposure is current.
2. Tie it to one concrete page action
Do not review the string in isolation. Trigger one action and inspect whether the key becomes active in a real browser flow. That tells you much more than a static code match ever will.
3. Inspect the request family around it
Look at destination hosts, methods, response behavior, and whether the key stays inside a narrow service boundary. A key that only appears in one constrained browser integration usually tells a different story from a key that seems to travel across multiple sensitive requests.
4. Write the narrowest supportable claim
A strong review note sounds like this: the browser-visible key is actively used in flow X, appears limited to service Y, and may still need manual validation for backend restrictions. It should not jump straight to "unrestricted leaked secret" unless the evidence really earns that language.
Common false positives
- Publishable frontend identifiers: some integrations are designed to expose a browser-side key safely within tight limits.
- Dead config residue: historical values can stay in bundles after the underlying path changed.
- Opaque non-secret strings: not every long value is a meaningful credential.
- Single-hit regex findings: a match with no runtime support is often too weak to classify confidently.
Limits and what this does not prove
Browser evidence does not prove the full scope of backend enforcement, whether a key is accepted outside the observed page flow, or whether abuse is truly possible. It also does not prove breach, account compromise, or exploitability. Public visibility is a signal. Impact still has to be earned with stronger evidence.
When to escalate
- The key is used in live runtime flows tied to cost, privileged actions, or sensitive data handling.
- The browser appears able to call provider-facing or internal-looking endpoints directly.
- You can reproduce the same behavior across sessions, assets, or routes, which raises confidence the key is active and operationally relevant.
- The finding materially changes how a reviewer should think about the app's trust boundary, even if impact is not yet proven.
Methodology + last reviewed
This article is based on browser-visible evidence only: exposed strings, current assets, runtime requests, and surrounding request context. It deliberately separates observed behavior from inferred impact. Last reviewed: 2026-04-06.
Use Source Detector to review the key together with the evidence around it
Source Detector helps you inspect source maps, suspicious strings, and request behavior in one workflow, so API key findings stay grounded in what the browser really showed.
FAQs
Does a browser-visible API key always mean unsafe exposure?
No. Some keys are intentionally public and tightly limited. The real question is what the browser can do with them.
What makes a visible key more concerning?
Live use in sensitive flows, weak-looking scope boundaries, and behavior that seems to authorize costly or privileged actions are stronger signals than static exposure alone.
Can frontend evidence prove a key is fully restricted?
No. Frontend evidence can reveal clues, not the complete backend policy.