Why do client-side applications create identity and access risks?

Why This Matters for Security Teams

Client-side applications sit in an exposed trust zone. Any token, cookie, API key, embedded configuration, or workflow logic delivered to the browser can be inspected, copied, or altered by a user, extension, proxy, or injected script. That is why identity and access risk in the client is not just a coding issue, but a control design issue. NIST’s control families around authentication, session management, and configuration management in the NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they frame what must stay protected, rotated, and monitored.

Teams often underestimate how quickly browser-exposed artefacts become durable access. Short-lived tokens are safer than long-lived ones, but if refresh tokens, local storage items, or API credentials persist in the client, the application can drift into standing access without any obvious alarm. The same applies when front-end logic enforces authorization decisions that should have been made server-side. In that case, the browser becomes part of the access control plane, which is a fragile design choice.

This issue also intersects with non-human identity governance when front-end applications call APIs using service credentials or delegated tokens. The OWASP Non-Human Identity Top 10 is useful here because it highlights how secrets, token sprawl, and weak lifecycle controls create reuse risk across machine identities. In practice, many security teams encounter client-side identity failures only after a token leak or script injection has already turned a convenience feature into an access path.

How It Works in Practice

The browser is not a trusted execution environment. It can display interface state, but it cannot reliably protect secrets or enforce high-value authorization on its own. In secure designs, the client requests access, but the server validates identity, privilege, and session state before any sensitive action occurs. That means the browser should carry as little authority as possible, with access scoped, time-bound, and revocable.

Typical implementation patterns that reduce risk include:

• Keeping secrets out of JavaScript bundles, local storage, and source maps.
• Using short-lived access tokens and server-side session controls where feasible.
• Applying strict content security policies and dependency controls to reduce script injection paths.
• Validating authorization on the server for every protected operation, not just at page load.
• Separating user identity from machine credentials when the front end calls downstream services.

The operational question is not just whether a token is present, but whether the token is exposed to inspection, replay, or misuse. Controls in the NIST Cybersecurity Framework 2.0 map well to this problem because they emphasise governance, protection, detection, and response across application and identity layers. For example, if a browser-held token is stolen, teams need telemetry that can spot anomalous use, a revocation path that works quickly, and a clear owner for the downstream identity.

For non-human identities, the same logic applies to client-side integrations that embed API keys or OAuth client material. Those credentials should be treated as replaceable, narrowly scoped, and aggressively monitored, not as static application fixtures. Client-side designs also need to account for third-party scripts, browser extensions, and user-controlled devices, since any of those can alter execution or exfiltrate data. These controls tend to break down when a single-page application uses long-lived tokens in local storage and relies on client-side checks for authorization, because the browser can be modified faster than the security model can respond.

Common Variations and Edge Cases

Tighter client-side controls often increase engineering overhead, requiring organisations to balance user experience against the need to minimise exposed authority. That tradeoff is especially visible in single-page applications, mobile web views, and third-party embedded components, where convenience often pressures teams to keep more state in the client than is ideal.

Best practice is evolving for token handling in browser-based applications, and there is no universal standard for every architecture. Some environments can use backend-for-frontend patterns to keep secrets off the browser entirely. Others may need carefully constrained OAuth flows with rotating tokens and strong replay protections. What matters is not the label of the pattern, but whether the browser is prevented from becoming a durable repository of reusable access.

Edge cases also appear when business teams want client-side feature gating, offline capability, or locally cached permissions. Those requirements can be legitimate, but they should never be treated as authoritative access decisions. Any cached entitlement should be considered advisory, with server-side revalidation before sensitive actions. This is particularly important when an application supports both human users and machine actors, because the same session mechanics can accidentally grant one identity class privileges intended for another.

Where identity risk becomes highest is when browser code distributes or refreshes credentials for downstream services without clear ownership, rotation, or revocation. At that point, the client is not just rendering a workflow, it is acting as an identity broker. That design can work in narrow cases, but it should be explicitly governed, audited, and treated as a temporary control rather than a default architecture.

Related resources from NHI Mgmt Group

• Why do LLM applications create new data leakage risks for identity teams?
• Why do conversational AI systems create new identity and access risks?
• Why does shared-device access create special identity risks in healthcare?
• Why do on-premises AI systems create new identity and access risks?