What breaks when low-code apps expose secrets in the browser?

Once secrets or privileged tokens appear in browser-delivered code, attackers can inspect bundles, replay requests and probe backend APIs without defeating the login flow. The real failure is not only secret leakage. It is the collapse of the trust boundary between the client and the service, which can expose data, permissions and internal routes.

Why This Matters for Security Teams

When a low-code app emits secrets into browser-delivered code, the problem is not limited to one exposed token. It usually means the application has pushed trust decisions into an environment the defender does not control. That can undermine API authorisation, enable request replay, and reveal internal endpoints that were assumed to be private. OWASP’s OWASP Non-Human Identity Top 10 is useful here because browser-exposed secrets often turn ordinary app components into unmanaged identities with standing access.

Security teams often miss this because low-code platforms make the visible interface look simple while hiding substantial backend privilege. The immediate issue is not always credential theft in the classic sense. The deeper failure is that the browser becomes a place where authentication material, session scope and business logic are all easier to inspect and abuse. That creates a gap between what the app owner thinks is protected and what the client can actually see or replay.

In practice, many security teams encounter this only after an exposed API is scraped, an internal function is discovered or a privileged workflow has already been automated by an attacker rather than through intentional testing.

How It Works in Practice

Low-code systems often assemble application logic through components, connectors and generated client code. If a secret, API key or privileged token is embedded in that client path, the browser can expose it through source inspection, network traces, cached responses or JavaScript bundle analysis. Even when the value is short-lived, the damage can still be meaningful if the token authorises broad actions or can be exchanged for a longer-lived session.

Defensive design should assume that anything sent to the browser can be read, copied and replayed. Good practice is to keep secrets server-side, scope every token narrowly, and route sensitive operations through a backend that enforces policy rather than trusting the client to behave. For low-code environments, that usually means:

• Store credentials in a server-side vault or managed secret store, not in page logic or browser variables.
• Use short-lived, scoped tokens with explicit audience and action limits.
• Separate read-only UI calls from privileged write actions.
• Log and monitor token usage for abnormal geography, volume or replay patterns.
• Review generated code and connectors as part of release approval, not after deployment.

From a broader control perspective, this aligns with NIST guidance on least privilege and secure architecture, and with the AI and automation risks described in NIST’s AI Risk Management Framework when low-code apps also orchestrate AI services or agentic workflows. If the application embeds model keys, retrieval credentials or tool tokens in the browser, those become operational secrets with the same exposure pattern as any other privileged identity. The lesson is similar to the one highlighted in the Anthropic report on AI-orchestrated cyber espionage: once a controller can be observed and manipulated, the attacker no longer needs to break the perimeter in the traditional sense.

These controls tend to break down when the low-code platform auto-generates front-end calls for privileged workflows because developers assume the platform’s abstraction layer is equivalent to a server-side trust boundary.

Common Variations and Edge Cases

Tighter secret handling often increases implementation overhead, requiring organisations to balance developer speed against the need for durable trust boundaries.

Not every exposed value is equally dangerous, and current guidance suggests organisations distinguish between public configuration data, low-risk client parameters and true secrets. There is no universal standard for this yet across all low-code products, so teams need to review what the browser can access on a case-by-case basis. A harmless-looking identifier can still become sensitive if it reveals tenant structure, internal routes or a predictable object reference.

Edge cases also appear when low-code apps are used for internal tools, admin portals or agentic workflows. In those environments, teams sometimes assume reduced risk because users are authenticated employees. That is a mistake. If browser-exposed credentials can reach privileged APIs, an internal account can become a launch point for data extraction, shadow automation or lateral movement. This is especially important when non-human identities are involved, because a browser-exposed token may effectively act as an unmanaged NHI with standing privilege.

The right question is not only whether the app works, but whether a user can inspect enough of the client to reconstruct the service’s trust model. If the answer is yes, then the application has already moved sensitive control logic into the wrong layer.

Related resources from NHI Mgmt Group

• What breaks when secrets are embedded in browser code?
• What breaks when secrets are stored in code and CI/CD tools?
• What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
• What breaks when browser extensions are treated as low-risk add-ons?