Frontend Secret Leaks in Generated Apps

Frontend secret leaks get more dangerous when software can create new customer-facing pages in minutes.

A security researcher published a current example from a network camera vendor. After unpacking firmware, he found a GitHub token duplicated in roughly 30 files. He wrote that the token had admin access to hundreds of repositories in the company's GitHub organization. The apparent cause was ordinary and painful: a frontend build had written the CI job's environment into shipped JavaScript.¹

The camera story is an old web security failure, not a strange AI failure. The reason it matters now is that generated apps increase the number of frontends a product team may create, test, and share.

Key Takeaways

• OWASP's testing guide names frontend JavaScript as a place sensitive information can leak, including API keys and internal endpoints.²
• Generated pages should be treated as untrusted clients, even when they were created inside your own product.
• Keep secrets server-side. Give generated pages narrow, audited capabilities instead of raw credentials.

Why do frontend secret leaks happen? #

Frontend secret leaks happen when build-time or server-only values cross into code that the browser can download.

In normal web development, that can happen through a bad environment variable pattern, a source map, a bundled config object, a copied .env file, or a debug endpoint left on. The camera story is a clean version of the mistake. The researcher found what looked like the CI environment written into the web UI bundle, including a GitHub token.¹

Modern frameworks try to reduce this risk. Vite, for example, only exposes environment variables prefixed with VITE_ to client code by default, specifically to prevent accidental leakage.³ That guard helps, but it is not a security model by itself. Teams can still pass the wrong object, serialize too much config, or build their own bridge around the framework's safe default.

The browser is not a private runtime. Anything sent to it should be considered visible to the user and to anyone who can inspect the page.

What changes when apps are generated? #

Generated apps change the speed and volume of frontend creation.

A product team used to ship a small number of carefully reviewed pages. A customer-facing builder changes the shape. A solutions engineer might generate a prospect-specific dashboard. A customer success manager might create an account health view. A customer might build a workflow screen for their own team.

That speed is the point. It is also the risk.

If every generated page can choose its own data path, secrets path, and write path, the team has not built a product capability. It has created a faster way to make security mistakes. The right boundary has to sit outside the generated code, not inside the prompt that produced it.

That means the generated frontend should never receive a database credential, a GitHub token, a model provider key, or a broad internal service token. It should receive only public config and temporary, user-scoped state. Everything sensitive should stay behind a server endpoint that checks tenant, role, workflow, and allowed action.

What should a generated page be allowed to know? #

A generated page should know only what a normal browser client is allowed to know.

That includes its display state, public feature flags, the current user's visible fields, and the specific API routes approved for that workflow. It does not include CI variables, server secrets, source control credentials, raw database URLs, privileged service tokens, or broad internal network locations.

This sounds basic because it is basic. The mistake is assuming a generated page is safer because it was produced by the platform. It is not. Once it runs in the browser, it is client code.

For SaaS products, the safer pattern is a capability layer:

• the generated page calls an app-specific server endpoint;
• the endpoint maps the request to approved product APIs;
• the host product enforces tenant isolation and role permissions;
• writes are narrowed, logged, and reviewable;
• secrets never leave the server runtime.

The page can still feel flexible. It can render charts, forms, filters, and workflow steps. It just cannot invent a new privileged path because the user typed a persuasive prompt.

How should teams review generated apps before sharing? #

Generated apps need a review gate that checks boundaries, not only whether the UI works.

A visual QA pass catches broken charts and awkward layouts. It does not catch a secret embedded in a bundle. It also does not catch a write action pointed at the wrong endpoint. Security review for generated apps should be mechanical wherever possible.

At minimum, the platform should check:

• no secrets or restricted environment variables appear in the generated bundle;
• all network calls use approved relative routes or approved domains;
• every API call maps to a declared capability;
• write actions require explicit permission and audit logging;
• app sharing has an owner, version, and rollback path.

GitHub's own guidance for exposed secrets starts with revocation. For GitHub personal access tokens leaked in public repositories, GitHub says it automatically revokes them.⁴ That is useful remediation. It is still remediation after the boundary already failed.

Generated app platforms should catch the failure before the page is published.

What does this mean for B2B SaaS teams? #

B2B SaaS teams should separate generation speed from execution privilege.

Let the AI move fast where speed helps: layout, data presentation, workflow copy, field selection, and interaction design. Keep privilege boring. The generated page should get a small set of capabilities that product and engineering already approved.

That is also how a customer-built page becomes easier to trust. Security does not have to approve a vague promise that generated code is safe. They can inspect the server-side capability map, the allowed APIs, the audit log, and the review state.

Gigacatalyst is built around that split. Users can create focused in-product apps quickly, but the app still runs through the host product's APIs, authentication, permissions, and review model. The generated frontend is not allowed to become its own little backend with secrets in the browser.

FAQ #

Conclusion #

The camera story is memorable because the mistake is so ordinary. A build environment crossed into a browser bundle, and a token that should have stayed private became visible in shipped code.

Generated apps do not change the rule. They make the rule more important. The frontend is public. Secrets stay server-side. Anything a generated page can do should be granted through a narrow capability the product already knows how to govern.

Sources #

Footnotes #

1. hhh. "My security camera shipped a GitHub admin token in its login page." https://hhh.hn/hanwha-github-token/. July 2026. ↩ ↩²

2. OWASP Web Security Testing Guide. "Review Web Page Content for Information Leakage." https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Web_Page_Content_for_Information_Leakage. Accessed July 24, 2026. ↩

3. Vite. "Env Variables and Modes." https://vite.dev/guide/env-and-mode. Accessed July 24, 2026. ↩

4. GitHub Docs. "Remediating a leaked secret in your repository." https://docs.github.com/en/code-security/tutorials/remediate-leaked-secrets/remediating-a-leaked-secret. Accessed July 24, 2026. ↩