Since I published my overview of the Backend for Frontend (BFF) pattern, the questions I've received fall into surprisingly consistent patterns. The same misunderstandings come up again and again, from developers who genuinely want to build secure apps.

Most of these misconceptions aren't just academic. They lead teams to ship apps with real security gaps while believing they've done the right thing. Let me address the ones I see most often.

Why PKCE Isn't a Replacement for BFF

This is the one I encounter most, and it's the most consequential.

The OAuth working group deprecated the Implicit Grant for SPAs and recommended Authorization Code with PKCE as the replacement. That guidance is correct. In addition, OAuth 2.1 recommends PKCE for any client, not just SPAs. Somehow, many developers concluded that PKCE also addresses token storage security. It doesn't.

PKCE (Proof Key for Code Exchange) protects the authorization code in transit. It prevents an attacker who intercepts the authorization code from exchanging it for tokens. Valuable, but it solves only one step of the OAuth flow.

Once your app receives tokens, PKCE has done its job. It has nothing to say about where those tokens live in the browser or what happens if a Cross-Site Scripting (XSS) attack runs in your app's context. Tokens in localStorage, sessionStorage, or even JavaScript memory are all reachable by malicious scripts.

BFF solves a different problem: it keeps tokens out of the browser entirely. The BFF exchanges the authorization code for tokens and stores them server-side. The browser gets an HttpOnly session cookie. An XSS attack running in that browser can't steal what isn't there.

PKCE and BFF are complementary, not alternatives. If your threat model includes XSS (and for most apps, it should), PKCE alone isn't enough.

BFF Is Not Just a Proxy

In a couple of cases, I've reviewed architectures labeled as "BFF" that were actually reverse proxies forwarding requests (and tokens) to a backend. That's not a BFF.

The defining characteristic of a Backend for Frontend is that it acts as a confidential OAuth client. It holds a client secret. It handles the full OAuth flow, including token exchange. Most critically, tokens never leave the server.

A reverse proxy that forwards an Authorization header containing a bearer token is not a BFF. The token is still accessible to the browser. You've added a network hop without the security benefit.

The IETF OAuth 2.0 for Browser-Based Apps BCP actually distinguishes between a Token-Mediating Backend (a backend that obtains tokens and then forwards them to the frontend) and a proper BFF (where tokens are never passed to the frontend at all). These are different patterns with different security properties.

If your backend is passing tokens to the browser in any form, you haven't implemented BFF. You've implemented token mediation, which is better than nothing, but it's not the same thing.

No, Cookies Are Not Less Secure Than Tokens

This one has roots in a legitimate historical concern. Cookies have a complicated reputation: they've been misused, and Cross-Site Request Forgery (CSRF) attacks were a real problem before SameSite became standard. Some of the "don't use cookies" instinct also came from REST API orthodoxy, where stateless communication was treated as a design virtue.

But here's what modern reality looks like: an HttpOnly session cookie cannot be read by JavaScript. That means XSS attacks can't steal it directly. A JWT in localStorage can be read by any script running on your page.

The attack surface isn't symmetric. A CSRF attack using an HttpOnly cookie requires the attacker to trick a user into making a specific authenticated request from another origin. An XSS attack that steals a localStorage token gives the attacker full, direct access to call any API as that user, from anywhere, without any user interaction required.

With SameSite=Strict or SameSite=Lax, CSRF attacks against HttpOnly cookies are already difficult in most real-world scenarios. Add explicit CSRF tokens and they become practically infeasible.

HttpOnly cookies aren't immune to CSRF, but the attack surface is far smaller than XSS-based token theft. You're trading one attack vector (XSS-based token theft) for a different, more constrained one (CSRF). That trade is almost always worth making.

BFF Does Not Solve All Your Browser Auth Security Problems

BFF shifts the security boundary. It doesn't eliminate it.

When you adopt BFF, you trade the token theft problem (XSS can steal tokens from browser storage) for the session management problem (your BFF now manages sessions and those need to be secured properly). This is a good trade in most cases, but it comes with responsibilities that BFF doesn't automatically fulfill.

Things BFF does not handle on its own:

• CSRF protection. Your BFF uses cookies, which means state-changing requests need CSRF protection. SameSite cookies help significantly, but this is still your responsibility to configure correctly.
• Session invalidation. When a user logs out, you need to revoke the session server-side, not just clear the cookie client-side. If you don't, stolen session cookies remain valid until natural expiry.
• Secure cookie configuration. Secure, HttpOnly, and the right SameSite setting are all required. Missing any of them weakens the pattern's security properties.
• Authorization checks in your API. BFF protects the token in transit. It doesn't automatically secure your API endpoints. You still need proper authorization logic on the backend.

Don’t implement BFF and then relax your overall security posture, assuming the pattern covers everything. It doesn't. Treat it as one layer in a defense-in-depth approach.

You Don’t Need to Rewrite Your Entire Application

The assumption that teams must rewrite the entire application prevents them from adopting BFF even when they should.

The full vision of BFF, as Sam Newman originally described it, is a server tailored to the specific needs of one frontend. That can mean a significant rearchitecting effort. But you don't have to implement the full pattern at once to get the security benefits.

In practice, many teams introduce BFF incrementally. The most common path:

1. Add a lightweight backend (Node.js, Next.js server components, ASP.NET Core, Python, or whatever fits your stack) that handles the OAuth flow.
2. The BFF exchanges authorization codes for tokens, stores them server-side, and issues session cookies to the browser.
3. Your existing frontend continues making API calls, now using session cookies instead of bearer tokens.

Your existing backend APIs often don't change at all. You're inserting the BFF as the authentication layer, not replacing your entire architecture.

The incremental path is real, and the auth-focused version of BFF is where most of the security value lives anyway.

Start With the Threat Model

Before deciding whether to implement BFF, be honest about your app's threat model.

If your application handles sensitive data, if XSS is a credible risk (and it usually is, especially for apps loading third-party scripts or rendering user-generated content), or if you operate in a regulated industry, BFF is the right choice. The complexity cost is manageable and the security benefit is concrete.

If you're building a simple public-facing app with no sensitive user data and strong existing XSS defenses, a well-implemented SPA with PKCE and in-memory token storage may be acceptable.

The BFF pattern exists because the browser is a hostile environment for tokens. If that threat is real for your application (and you're the best judge of that) BFF addresses it in ways that PKCE and in-browser token handling simply can't.