When should organisations use a backend-for-frontend instead of handling tokens entirely in the browser?

Organisations should use a backend-for-frontend when the application handles sensitive data, has a larger attack surface, or must reduce token exposure in untrusted client code. The pattern keeps token exchange and storage closer to the server, where controls are stronger than in the browser. It is especially useful when refresh token theft would create unacceptable account takeover risk.

Why This Matters for Security Teams

A backend-for-frontend changes where trust is enforced. When tokens live only in the browser, every XSS flaw, malicious extension, compromised device, or overly permissive third-party script becomes a potential path to token theft. That is why the browser is a poor place to hold long-lived refresh tokens or broad-scoped access tokens for sensitive workflows. NIST SP 800-53 Rev. 5 emphasises controlling authenticator handling and session integrity, but the practical challenge is that web clients remain untrusted by design.

The issue is not simply “frontend versus backend.” It is whether the application can keep credentials inside a boundary that supports stronger policy, logging, and revocation. NHIMG research on The State of Secrets Sprawl 2026 shows how often valid secrets remain exploitable after exposure, which is exactly the risk profile that browser-held tokens create. In real incidents such as the Salesloft OAuth token breach, token theft was enough to turn a single exposure into downstream account compromise. In practice, many security teams discover this only after a browser-side token has already been replayed from somewhere they never intended to trust.

How It Works in Practice

A backend-for-frontend, or BFF, acts as a server-side intermediary between the browser and upstream APIs. The browser authenticates to the BFF, usually with a same-site session cookie, and the BFF holds or exchanges the real API tokens on the server side. That means the frontend never sees the most sensitive credentials, which reduces the blast radius of XSS and token leakage.

In a typical design, the BFF performs token exchange, attaches access tokens to outbound API calls, and stores refresh tokens in server-side session storage or another controlled backend store. Current guidance suggests short-lived access tokens, per-session or per-user token binding where feasible, and strict revocation on logout or anomaly detection. This aligns with the control intent in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially around session management, least privilege, and auditability.

• Use the BFF when the browser must never handle refresh tokens directly.
• Prefer same-site, HttpOnly, Secure cookies for browser-to-BFF sessions.
• Keep upstream API tokens server-side and rotate them aggressively.
• Log token exchange, refresh, and revocation events for detection and response.

NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because the BFF is partly a containment strategy: it reduces how many places a secret can leak and how many client paths can expose it. These controls tend to break down when the application is built as a pure static SPA with no server session layer and no secure backend boundary for token handling.

Common Variations and Edge Cases

Tighter token containment often increases operational overhead, requiring organisations to balance reduced exposure against added backend complexity and session-state management. That tradeoff is worth it for higher-risk applications, but it is not always necessary for every frontend. For low-risk, low-privilege apps, browser-based flows with narrowly scoped, short-lived tokens may be sufficient if the threat model tolerates some client exposure.

There is no universal standard for this yet, but current guidance suggests choosing a BFF when the application needs one or more of the following: privileged downstream APIs, sensitive customer data, step-up authentication, refresh tokens, or strong revocation guarantees. It is also a strong fit when security teams need centralized policy enforcement, because the backend can evaluate access before each call instead of relying on static client permissions.

Edge cases matter. A BFF can still become a liability if it stores tokens without rotation, if it overbroadly reuses user sessions, or if the backend becomes a single point of compromise. In highly distributed architectures, teams sometimes use a hybrid pattern: public data stays browser-accessible, but sensitive actions are proxied through the BFF. That approach can work well, but it requires disciplined separation of scopes and careful review of which requests truly need server-side mediation. The pattern becomes less effective when the frontend is offline-first, heavily third-party embedded, or expected to operate without a reliable server round trip.

Related resources from NHI Mgmt Group

• How do organisations decide when to use dependency-driven orchestration instead of separate stack runs?
• Should organisations use remote browser isolation instead of traditional endpoint controls?
• Should organisations use a backend for frontend in web modernisation projects?
• When should organisations use browser redaction instead of relying on redaction APIs?