Should organisations use a backend for frontend in web modernisation projects?

Organisations should use a backend for frontend when they want modern UI delivery without pushing security-critical session handling into the browser. A BFF can centralise OAuth code flow handling, token exchange, and cookie issuance, which simplifies the frontend and makes the security model easier to govern.

Why This Matters for Security Teams

A backend for frontend, or BFF, is not just an architecture choice. It changes where authentication, session state, and token handling live, which matters because browser-based applications are harder to secure consistently across devices, extensions, and third-party scripts. A BFF can keep OAuth code flow handling server-side, issue same-site cookies, and reduce the chance that access tokens end up exposed in client-side code or local storage.

This is especially relevant in modernisation projects where teams are replacing server-rendered apps with single-page or mobile-first front ends. Without a BFF, security teams often push sensitive decisions into the browser and inherit a much larger attack surface. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap is often mirrored in application-layer identities and tokens as well. The broader identity and secrets exposure patterns described in the Ultimate Guide to NHIs show why token placement and lifecycle control are not cosmetic design choices.

In practice, many security teams discover session and token exposure only after a frontend integration has already gone live, rather than through intentional architecture review.

How It Works in Practice

In a BFF pattern, the browser never talks directly to downstream APIs with long-lived bearer tokens. Instead, the frontend authenticates to the BFF, the BFF completes the OAuth authorization code flow, exchanges the code for tokens, and stores those tokens server-side. The browser receives only a session cookie or similar narrow credential, while the BFF acts as the policy enforcement and token mediation layer.

That design supports cleaner governance in modernisation programmes because the frontend becomes less sensitive to identity protocol details. It also creates a better place to apply runtime controls such as request validation, CSRF protection, audience restrictions, and token translation for multiple downstream APIs. This is aligned with the direction of the NIST Cybersecurity Framework 2.0, which emphasises structured governance, access control, and resilience across the application lifecycle.

For security teams, the practical checklist usually looks like this:

• Keep browser tokens short-lived or eliminate them entirely in favour of an HttpOnly session cookie.
• Centralise OAuth callbacks and token exchange in the BFF, not in JavaScript.
• Limit the BFF to the minimum API scopes needed for the user’s current task.
• Use server-side logging and monitoring to trace token use, revocation, and unusual request patterns.
• Treat the BFF as a privileged application component with hardened secrets handling and release controls.

This approach pairs well with the NHI lifecycle and secret-rotation guidance in the Ultimate Guide to NHIs, especially when the frontend must call multiple APIs or when access to downstream services changes frequently. These controls tend to break down when teams reintroduce direct browser-to-API calls for convenience because token sprawl returns immediately.

Common Variations and Edge Cases

Tighter token containment often increases platform overhead, so organisations need to balance improved browser security against extra backend complexity and latency. That tradeoff becomes visible during migrations, where teams may want a BFF for web but not for every channel or internal tool.

There is no universal standard for when a BFF is mandatory. Current guidance suggests it is most valuable when the frontend cannot safely hold credentials, when multiple backends need a single coherent auth boundary, or when compliance requires stronger server-side control over session management. It is less compelling for simple static sites with no sensitive authenticated operations.

Two edge cases come up often. First, teams sometimes build a BFF but still let the frontend cache tokens or call APIs directly, which defeats the pattern. Second, if the application depends on third-party embedded widgets or cross-origin workflows, the BFF may need extra consent and token-exchange logic to avoid breaking user experience. For broader identity risk context, NHI Mgmt Group’s Ultimate Guide to NHIs is useful because the same lifecycle discipline that protects service accounts also applies to server-side session bridges.

In mature environments, the real question is not whether a BFF is trendy, but whether the organisation is prepared to operate it as a security boundary rather than a convenience layer.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• When does regex-based secret detection become too unreliable for production use?