Teams should avoid placing long-lived API keys in the browser and instead route requests through a trusted proxy or relay that issues temporary credentials. That keeps client exposure limited, preserves server-side control, and reduces the blast radius if frontend code is inspected. For production, the control point should sit behind authenticated backend logic, not inside user-facing JavaScript.
Browser Access Needs a Server-Controlled Trust Boundary
Browser-based Realtime API access is a security design problem, not just a frontend convenience problem. If the browser can hold durable secrets, any user with developer tools, injected script, or compromised extensions can copy them and reuse them outside the intended session. The safer pattern is to keep the trust decision on the server and issue only short-lived credentials for the specific browser session. That preserves control over who can connect, what they can do, and how quickly access can be revoked. For a broader control view, NIST’s security control catalogue is useful because it frames the problem as access enforcement, credential handling, and boundary protection rather than as a purely client-side implementation detail. In practice, many teams discover the weakness only after frontend code, logs, or shared environments have already exposed the credential.
How Relay-Based Access Works in Practice
The practical model is simple: the browser authenticates to your application, your backend decides whether the user or session is allowed to use the Realtime API, and then the backend returns a temporary credential or forwards the request through a relay. The browser never sees a reusable long-term secret. Instead, it receives only the minimum access needed for the current interaction, with a short lifetime and narrow scope.
This pattern matters because browser code is inherently inspectable. Even if you hide a key in obfuscated JavaScript, it remains recoverable once the page runs. A relay or trusted proxy changes the security boundary: authentication, authorization, quota enforcement, and logging all happen in a place you control. That also gives you a clean place to enforce tenant separation, rate limits, origin checks, and session binding. If the Realtime API supports ephemeral tokens, those should be minted server-side and tied to the user session, not generated in the browser.
A strong implementation usually has three steps. First, authenticate the user to your own application. Second, apply your own policy decision about whether the user should be allowed to open a realtime session. Third, issue a short-lived access grant or proxy the connection through a backend service that can enforce policy throughout the session. The relay should log who requested access, when it was granted, and when it expired, because that evidence is often what separates a controlled session from an unauthorised one.
- Keep the browser limited to session-scoped access, never reusable production secrets.
- Bind the credential to a specific authenticated user or application session where possible.
- Enforce expiry aggressively so leaked material becomes useless quickly.
- Put quota, origin, and authorization checks behind your backend, not in frontend code.
This guidance breaks down when teams try to let the browser act as the trust anchor, because at that point revocation, attribution, and policy enforcement become unreliable.
Where the Pattern Gets Fragile: Public Clients, Multi-Tenant Apps, and Token Leakage
Tighter browser access controls often increase implementation overhead, requiring teams to balance user experience against the cost of operating a backend relay or token issuer. That tradeoff becomes more visible in public-facing apps, embedded widgets, and multi-tenant products where the browser is not fully trusted and the session boundary is harder to define.
The main edge case is a public client that must start quickly and cannot rely on a pre-authenticated user session. In those cases, teams sometimes over-broaden token scope or extend token lifetime to reduce friction, which weakens the control. Another common exception is development tooling: test keys, staging credentials, and demo environments often leak into production workflows because they feel harmless. They are not harmless if the same browser bundle ships to real users. This is also where the browser and the backend need different rules, because frontend exposure is inevitable while server-side exposure is governable.
One useful link between identity security and this browser pattern is that temporary credentials behave like non-human identity material even when the primary goal is just browser access. That means ownership, rotation, expiry, and revocation still matter, even if the user experience is framed as “just a web session.” The OWASP Non-Human Identity Top 10 is a relevant reference here because it helps teams think about short-lived access material as something that still needs lifecycle control, not as disposable implementation glue. The point is not to turn this into an NHI project; it is to avoid treating ephemeral browser tokens as if they were harmless because they are temporary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Browser access should be mediated by controlled, least-privilege session access. |
| 3 — Data Protection | Long-lived API keys in frontend code expose sensitive credentials to inspection and reuse. | |
| Recommendation — Enforce least-privilege session access and remove reusable secrets from browser-delivered paths. Protect credentials in server-side storage and limit exposure to browser-delivered material. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The pattern is fundamentally about enforcing access from a trusted backend boundary. |
| PR.DS — Data Security | Ephemeral tokens and API secrets require protection against leakage and reuse. | |
| Recommendation — Centralize authentication and authorization before issuing any session-scoped API access. Minimize secret exposure and keep credentials short-lived and tightly scoped. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Embedded browser secrets are recoverable through client inspection or source review. |
| Recommendation — Detect and remove exposed client-side credentials before they can be reused. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Temporary browser credentials still need lifecycle control, expiry, and revocation. |
| Recommendation — Issue only short-lived credentials and govern their rotation, expiry, and revocation. | ||
Practitioner Guidance
What to prioritise: Treat the backend relay or token issuer as the control point, and verify that no durable secret is required for the browser to begin a realtime session. If a user can inspect page source or dev tools and recover something reusable, the design is too permissive.
What to verify: Confirm that the access grant expires quickly, is bound to the authenticated session, and cannot be reused across users, tabs, or environments. Also verify that revocation is operationally meaningful, not just documented, because a token that cannot be invalidated until expiry is still a live exposure.
Common mistake: Teams often secure the API key but leave the relay itself under-governed. That creates a false sense of safety, because the relay then becomes the real enforcement point and must be protected, monitored, and tested like any other privileged backend service.
Practitioner takeaway: The right question is not whether the browser can call the Realtime API, but whether the browser can do so without ever becoming a durable trust anchor; if it can, the control design is too weak.
Related resources from NHI Mgmt Group
- What do teams get wrong about browser-based access for OT?
- How should security teams govern consent-based API access in open banking?
- How should security teams compare API-based JIT access with proxy-based access control?
- How should security teams govern browser-based access to sensitive applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
