Why Backend for Frontend (BFF) beats OAuth tokens in browser storage

Backend for Frontend (BFF) has emerged as a go-to pattern for securing browser-based applications, yet many teams still misunderstand its role. When developers replace BFF with PKCE or raw cookies, they leave critical security gaps that malicious actors routinely exploit. The difference between a properly implemented BFF and a hastily assembled workaround can determine whether your application stays safe or falls victim to OAuth and XSS attacks.

PKCE secures the auth code, not token storage

Since OAuth 2.1 recommended PKCE for all client types, developers have often treated it as a complete security solution. PKCE indeed hardens the authorization code flow by ensuring intercepted codes can’t be exchanged for tokens. However, its protection ends once the tokens reach the browser. Whether stored in localStorage, sessionStorage, or JavaScript memory, tokens remain vulnerable to Cross-Site Scripting (XSS) attacks. An attacker who runs malicious JavaScript in a compromised page can read these tokens directly and impersonate users across APIs.

BFF addresses this gap by acting as the confidential OAuth client. It exchanges the authorization code for tokens on the server and stores them in a secure, server-side session. The frontend receives only an HttpOnly cookie, which JavaScript cannot access. In this setup, XSS can’t steal tokens because they never enter the browser in the first place. PKCE and BFF serve different layers of the security stack; they complement rather than replace each other.

BFF is not a reverse proxy or token forwarder

A common mislabeling mistake is calling any backend intermediary a BFF. True BFF implementations handle the full OAuth flow internally, including token exchange and storage, which keeps tokens off the client. A reverse proxy merely forwards requests—and often tokens—between the frontend and backend. If your architecture forwards an Authorization header containing a bearer token to the client, you’ve implemented token mediation, not BFF.

The IETF’s OAuth 2.0 for Browser-Based Apps Best Current Practice clarifies this distinction. A Token-Mediating Backend forwards tokens to the frontend, while a proper BFF never exposes tokens to the browser at all. The security benefits of BFF stem from this isolation. Without it, you gain an extra network hop but retain the same attack surface as storing tokens in localStorage.

Cookies under BFF are more secure than browser tokens

Historical concerns about cookies often lead developers to prefer storing JWTs in browser storage for perceived flexibility. Yet modern HttpOnly cookies offer stronger protection against XSS than localStorage tokens. JavaScript cannot read HttpOnly cookies, so XSS attacks gain no direct access to session data. In contrast, tokens in localStorage are readable by any script running in the page context, giving attackers immediate control over user sessions.

While cookies introduce potential CSRF risks, these are mitigated with SameSite policies and explicit CSRF tokens. A CSRF attack requires tricking a user into making a specific request, whereas an XSS attack with a stolen token allows full API access from anywhere without user interaction. The trade-off is clear: fewer, more constrained attack vectors (CSRF) versus direct, unlimited access (XSS token theft).

BFF shifts but doesn’t eliminate security responsibilities

Adopting BFF moves the security boundary from the client to the backend, which comes with its own requirements. BFF doesn’t magically secure your application—it changes what you need to secure.

• CSRF protection: State-changing requests must include CSRF defenses even with SameSite cookies. Configure tokens or headers appropriately to block forged requests.
• Session invalidation: Logging out requires server-side session revocation, not just clearing a client-side cookie. Otherwise, stolen cookies remain valid until expiry.
• Cookie hardening: Use Secure, HttpOnly, and the correct SameSite settings to prevent leakage and tampering.

These steps ensure that the backend session remains as secure as the frontend isolation BFF provides. Without them, attackers may still hijack sessions through CSRF or session fixation if configurations are weak.

As browser-based apps grow in complexity, so do their attack surfaces. BFF isn’t a silver bullet, but it corrects fundamental flaws in how many teams handle OAuth and token storage. When implemented properly, it reduces the most damaging attack vectors while shifting focus to manageable backend risks. The result is a more resilient application that protects users without sacrificing developer experience.