Key facts
- What it exposes: private API keys, cloud credentials, session tokens, internal endpoints, system prompts, and original source code.
- Where it happens: front-end bundles, inlined environment variables, public source maps, localStorage, sessionStorage, and readable cookies.
- Scale of the wider problem: GitGuardian found 23.8 million secrets leaked on public GitHub in 2024, up 25% year over year.
- Framework reference: the OWASP Top 10 for LLM Applications (2025) lists System Prompt Leakage as LLM07:2025.
- What it leads to: API and billing abuse, session hijacking, data access, and mapping of back-end attack surface.
How Client-Side Secrets Exposure Happens
A browser can only run code it receives, so anything placed in client-side code is public by design. Secrets usually reach the browser in one of five ways:
- Build tools inline environment variables. Front-end frameworks replace environment variables with their literal values at build time. A private key given a public prefix ships to every visitor.
- AI-generated code takes the shortest path. Coding assistants optimize for code that works. Asked to connect a front end to an AI model or payment API, they may place the key directly in client-side code.
- Prototypes reach production. A demo that calls an API from the browser becomes the live product without a security review.
- Source maps are published. Debugging files deployed to production expose the original, readable source and developer comments.
- Tokens live in web storage. Any first-party or third-party script on the page can read localStorage and sessionStorage.
AI also speeds up discovery. Large language models (LLMs) can read a minified bundle, explain it, and point to hardcoded keys and endpoints, which lowers the skill needed to find secrets.
Types of Client-Side Secrets
API keys and cloud credentials
Private keys for payment, AI model, mapping or messaging APIs, and cloud access keys end up in bundled application logic. Attackers can call the API as you, run up usage costs, and access the data behind it. Some keys, such as publishable payment keys, are designed to be public and scoped to safe actions. The risk comes from keys that were never meant to leave the server.
Session and access tokens
Tokens stored in localStorage, sessionStorage, or cookies without the HttpOnly flag are readable by every script on the page. A compromised or over-permissioned third-party script can collect them and hijack sessions.
Internal endpoints and admin routes
URLs for internal APIs, staging services, and admin functions reveal how the back end is built. Attackers use them to map the attack surface and target routes that lack server-side checks.
System prompts and AI configuration
Front-end code that calls LLM APIs directly can expose system prompts, model settings, and retrieval endpoints. Competitors can copy proprietary prompts, and attackers can learn guardrails in order to bypass them.
Source code and developer comments
Public source map (.map) files restore readable source, including variable names and comments developers never meant to publish.
Client-Side Secrets Exposure vs. Data Leakage
| Client-side secrets exposure | Data leakage | |
| What is exposed | Credentials, keys, tokens, endpoints, and configuration | Any sensitive data, often personal or business data |
| Where it happens | In code and storage delivered to the browser | Any system or channel |
| Cause | Secrets placed in client-side code or storage | Misconfiguration, human error, insecure tools or malicious scripts |
| Visible to | Every visitor and every script on the page | Depends on the channel |
| Primary fix | Keep privileged secrets server-side; restrict what scripts can read | Data classification, access control and data flow governance |
Why Client-Side Secrets Exposure Matters
- Financial loss. Exposed AI and cloud API keys can be used to run up usage charges on your account.
- Data access. Keys and tokens can unlock the data behind an API or a user’s session.
- Attack surface mapping. Exposed endpoints show attackers where to probe next.
- Loss of AI IP. Leaked system prompts give away work that differentiates your AI features.
- Compliance exposure. Credentials that unlock personal or payment data can create exposure under GDPR and PCI DSS v4.
- Long tail of risk. GitGuardian reports that 70% of secrets leaked in 2022 were still valid at the time of its 2025 report. Secrets that ship to the browser need rotating, not only removing.
Best Practices to Prevent Client-Side Secrets Exposure
- Keep privileged keys server-side. Route browser requests through a back-end proxy that holds the credential.
- Audit inlined environment variables. Check what your build tool replaces at build time, and never give private values a public prefix.
- Scope public keys tightly. Limit any key that must be public to the minimum actions, domains, and rate limits.
- Remove production source maps. Or restrict access to them.
- Review AI-generated front-end code. Treat it as untrusted until reviewed, and run secret scanning in CI/CD.
- Keep system prompts off the client. Call LLM APIs from the server.
- Prefer HttpOnly cookies for session tokens. Avoid storing them in web storage.
- Restrict what third-party scripts can read. Limit access to browser storage, cookies and form fields.
- Protect logic that must run in the browser. Use protection built to resist AI-assisted reverse engineering.
- Rotate anything that has shipped. Assume any secret that reached the browser has been seen.
Solutions by Jscrambler
The first fix is architectural: privileged secrets belong on the server. Obfuscation is not encryption, and no client-side control turns a private key into a safe one. For the sensitive values and application logic that must run in the browser, the Jscrambler Client-Side Security Platform adds runtime enforcement on both sides of execution.
- LLM-Resilient Code Protection. String and literal protection, polymorphic obfuscation, and LLM-Resilient protection dramatically increase the difficulty of extracting embedded values and the logic around them, including with AI-assisted analysis. Anti-debugging, anti-tampering, and Code Locks restrict how and where protected code runs.
- AI Data Governance & Security. Browser Storage Fencing and Cookie Fencing control which third-party scripts can read tokens and stored data. Network exfiltration control defines which data types may go to which destinations.
FAQs
Is minified JavaScript enough to hide an API key? No. Minification shortens code for performance. It does not hide string values, and LLMs can read minified code quickly.
Does obfuscation make it safe to put secrets in front-end code? No. Obfuscation raises the cost of analysis but is not encryption. Privileged secrets should stay on the server. Obfuscation protects the values and application logic that must run client-side.
Can third-party scripts read my tokens? Yes, if tokens are in localStorage, sessionStorage, or cookies without the HttpOnly flag. Every script on the page shares that access unless it is restricted at runtime.
How does AI-generated code increase secrets exposure? Coding assistants produce working code quickly and may place keys directly in client-side code to make an integration run. Without review, those keys ship to production.