How should security teams protect single-page applications from token exfiltration while preserving a good user experience?

Why This Matters for Security Teams

Single-page applications are attractive because they keep interactions fast, but the browser is still an exposed execution environment. If access tokens sit in browser JavaScript, any injected script, compromised dependency, or malicious extension can extract them and reuse them elsewhere. That risk is not theoretical. The Salesloft OAuth token breach is a clear example of how stolen tokens can become a direct path into business data, while the Guide to the Secret Sprawl Challenge shows how quickly credentials spread once they are copied into places they should never reach.

For security teams, the goal is not to block modern authentication patterns. It is to keep the browser responsive while removing long-lived token custody from JavaScript. That usually means a server-side trust boundary, short-lived session handling, and careful use of OAuth 2.0 and OpenID Connect so the SPA can still call APIs without becoming the token vault. NIST guidance on identity and access control supports this least-privilege approach in practice, especially when paired with strong session handling and token lifetimes in NIST Cybersecurity Framework 2.0. In practice, many security teams discover token theft only after a user session has already been replayed from somewhere the browser never should have trusted.

How It Works in Practice

The most resilient pattern is to keep the SPA as a presentation layer and move sensitive token handling into a trusted backend or dedicated BFF component. The browser authenticates the user, but the server holds the sensitive OAuth artifacts, exchanges codes, and talks to downstream APIs on the SPA’s behalf. That reduces exposure to XSS-driven token exfiltration and makes revocation, rotation, and session invalidation easier to control.

This approach works best when combined with a narrow session model and strict browser hardening. Practical controls include:

• Use authorization code flow with PKCE, but avoid storing long-lived access or refresh tokens in browser JavaScript.
• Prefer HttpOnly, Secure, SameSite cookies for the browser session, so scripts cannot read the session secret directly.
• Keep access tokens short-lived and scope them to a single API or action set.
• Apply CSP, dependency review, and output encoding to reduce script injection paths.
• Log and monitor token issuance, exchange, and refresh activity so anomalous reuse is visible early.

NHIMG research on identity exposure shows why this matters beyond theory: only 1.5 out of 10 organisations are highly confident in securing NHIs, and Astrix Security & CSA also found that 85% lack full visibility into third-party vendors connected via OAuth apps. That visibility gap makes token custody a security boundary, not an implementation detail. Modern session architectures should also reflect current OAuth guidance and defensive control mapping in NIST SP 800-53 Rev 5 Security and Privacy Controls.

These controls tend to break down when teams try to preserve a pure static frontend architecture while also requiring broad API access, because the browser ends up doing too much sensitive work for its threat model.

Common Variations and Edge Cases

Tighter token handling often increases backend complexity, requiring organisations to balance stronger containment against latency, deployment overhead, and developer friction. That tradeoff is usually worth it, but the design still needs to fit the application’s risk profile.

Some teams choose a token relay model for low-risk read-only apps, where the browser gets a narrowly scoped, extremely short-lived token. Current guidance suggests that this can be acceptable only when the blast radius is tiny and the app is hardened against script injection. There is no universal standard for this yet, so the decision should be based on data sensitivity, user population, and how often tokens can be revoked without breaking the experience.

Other edge cases include multi-tenant applications, embedded third-party widgets, and enterprise single sign-on flows. These often introduce hidden trust edges that make browser-held tokens harder to defend. For those environments, current best practice is to keep the SPA stateless, use backend-mediated token exchange, and treat the browser as an untrusted presentation layer rather than an identity container. Lessons from incidents such as the Vercel Context.ai OAuth Supply Chain Breach show how quickly an integration layer can become the weakest link when trust boundaries are unclear.

When UX must remain seamless, the safest compromise is short-lived, server-controlled sessions with aggressive revocation and a narrow API proxy surface, not long-lived browser tokens.

Related resources from NHI Mgmt Group

• Why do single page applications create more OAuth security risk than traditional web apps?
• How should security teams test single-page applications without relying on browser crawling?
• How should security teams validate web applications that use OAuth 2.0 or SSO without breaking the user experience?
• How should security teams implement fine-grained authorization for applications with orgs, workspaces, and projects?