Summary

  • RFC 10017, published in August 2026 as an IETF Best Current Practice, strongly recommends a Backend for Frontend for business, sensitive and personal-data applications because it keeps OAuth access and refresh tokens away from browser code.
  • The BFF removes several token-theft and fresh-token attacks, but malicious code sharing the application origin can still send requests through the cookie-backed session. Proof that no token escaped is not proof that no unauthorized action occurred.

A breach can leave every token in place

The opening is an analytical scenario, not a reported incident. Its point is deliberately narrow. A security team can verify that the access token never appeared in JavaScript memory, that the refresh token remained in a server-side store and that an HttpOnly cookie could not be read. Those are useful findings. They do not account for what code inside the origin was able to ask the browser and BFF to do.

RFC 10017 begins from this privilege boundary. Malicious JavaScript is not a lesser tenant inside the application. Once it executes in the same context, it can inspect page data, use origin storage, interact with same-origin contexts and send requests to backends. A compromised dependency does not need to extract a credential if the browser and BFF will exercise that credential on its behalf.

The document separates four scenarios. An attacker may steal the current tokens once, establish persistent theft as tokens rotate, obtain a fresh set through a new authorization flow, or proxy requests through the user’s browser. The last case is the important one here. Requests from malicious and legitimate code can be indistinguishable because both originate inside the application context. If another component attaches the access token, that component can attach it to the induced request too.

This distinction changes incident language. “No token theft” closes two evidence questions: whether a bearer value left custody and whether it could be replayed elsewhere. It leaves open whether the user’s session caused an unauthorized call, whether the call was within the BFF’s route map, and whether the resource server should have allowed the underlying action.

The BFF changes the attack, not the browser

A BFF takes three central duties. It acts as a confidential OAuth client, holds access and refresh tokens in a cookie-backed session context, and forwards requests to resource servers after adding the appropriate access token. Browser code sees the session interface rather than the token material.

That design effectively mitigates the RFC’s one-time theft, persistent theft and fresh-token acquisition scenarios. There is nothing in the browser to exfiltrate, and compromised code cannot exchange a new authorization code without the BFF’s client credentials. PKCE adds protection around the code exchange. The security gain is real and substantial.

But the remaining attack is also explicit. Malicious code still runs inside the application origin and can send requests to the BFF from the user’s browser. HttpOnly prevents direct reading of the session cookie; it does not stop the browser from including that cookie on a permitted request. The BFF can then select a token and forward the call without either secret becoming visible to the compromised code.

RFC 10017 therefore describes client hijacking as inherent to browser applications. The BFF narrows the attacker to the actions that the application, session, BFF and resource policies permit. It prevents escalation from client hijacking to portable session theft when cookie controls hold, but it does not make the code running in the client trustworthy.

That is why the BCP can strongly recommend the BFF for business, sensitive and personal-data applications while still documenting a residual attack. Architecture is comparative. A design may remove the most durable and transferable credential consequences without removing every way to abuse an active user context.

The cookie is unreadable, not inactive

RFC 10017 requires BFF cookies to use Secure and HttpOnly. It recommends SameSite=Strict, path /, no Domain attribute and a host-scoped HTTP prefix unless a deployment has a reason to depart. These controls protect the session entity against network exposure, script reading and broad subdomain sharing.

They do not answer whether the request itself was intended. Because the cookie authenticates browser-to-BFF interactions, the BFF must implement a proper CSRF defense. SameSite=Strict may be sufficient when no other application shares the site boundary, but sibling subdomains are same-site even when they are cross-origin. A subdomain takeover can therefore reopen a request-forgery route that a simple same-site check appeared to close.

CORS can become part of the defense, but its evidence must be specific. Some safelisted requests are sent without a preflight; the browser may merely withhold the response. A BFF that relies on preflight can require a custom header and reject every request that lacks it. An audit should prove that the requirement applies to all state-changing endpoints rather than recording only that “CORS is enabled.”

The session clock must also follow the token clock. When the refresh token expires or is invalidated, the BFF should not preserve an apparently active browser session that can no longer obtain legitimate access. Conversely, revoking a token without tracing the related session can leave investigators uncertain about which browser interactions were actually stopped.

A proxy map is an authorization surface

The BFF is not merely a safe place to store secrets. It is an application-layer proxy that translates an inbound cookie-backed request into an outbound bearer-authorized call. That translation is a control surface.

RFC 10017 requires strict outbound controls. Destination hosts must be allowlisted. Paths that contain dynamic values must be validated. Methods can be restricted per endpoint. Without those boundaries, an attacker may turn a legitimate session into an open forwarding service, direct a valid token toward an unintended host, or reach an operation the frontend never meant to expose.

This makes a route such as /bff/orders/{id} more than plumbing. Its mapping defines which resource, path and method the browser session can spend. The resource server must still validate audience, scope, subject and action-level policy. A correct BFF route does not prove that a refund, transfer or administrative change was authorized under current business rules.

Observed outcome completes the record. The BFF may log a successful upstream response while the resource service rejects the action asynchronously. It may also retry a request, concentrate many users behind one egress address, or encounter rate limiting designed for direct clients. Request ID, user session, route decision, token audience, resource decision and final state need a shared correlation surface.

The privacy boundary moves too. A BFF observes every forwarded request and response. If a third party hosts that component, server-side custody reduces browser token exposure while expanding what the intermediary can observe. Credential safety and data minimization are different decisions.

Three architectures preserve different evidence

The BCP ranks three patterns by security and complexity. A full BFF keeps both access and refresh tokens server-side and proxies every resource call. A token-mediating backend remains a confidential OAuth client and protects refresh tokens, but returns access tokens to the browser so it can call resource servers directly. A browser-only client handles the OAuth responsibilities and tokens in the browser.

The middle pattern removes less risk than its name may suggest. A compromised browser can steal the access token or use it through the application. It cannot normally take the protected refresh token or exchange a new code without backend credentials. This is a different evidence profile, not a partial BFF checkbox.

The browser-only pattern remains exposed to all four malicious-code scenarios. Authorization Code with PKCE is mandatory for such clients, and refresh tokens must rotate or be sender-constrained and must have a bounded lifetime. These controls constrain interception and persistence. They do not isolate hostile code that already shares the legitimate origin.

DPoP provides another useful but bounded control. A non-exportable key can make a stolen access token harder to use away from the browser. It does not prevent browser-mediated request proxying. Where compromised code can launch a fresh flow, it may bind the new tokens to its own key. “Sender constrained” must therefore identify which sender context and which flow created the binding.

Not every same-domain application needs OAuth between its frontend and API. RFC 10017 notes that a common-domain application can use federated authentication and then maintain its own application session. Adding OAuth where no independent resource relationship exists can introduce token and proxy surfaces without creating a new trust boundary.

Keep the security claim as narrow as the mechanism

RFC 10017 is valuable because it does not promise a browser enclave. It identifies attacks, compares consequences and assigns controls to distinct components. A BFF is a strong local answer to token exposure. It is not a statement that all code in the origin is authorized, all proxied requests express user intent, or every resource action is safe.

The operational record should preserve those differences. Store code and dependency provenance, origin, session issuance and expiry, cookie attributes, request time, method, path and body class, CSRF result, BFF route mapping, token audience and scope, resource policy decision, response, business effect and rollback owner. Each item has its own clock and responsible party.

This is also the thin-coordination lesson. A shared BCP can specify minimum secure patterns while adoption, application boundaries, endpoint allowlists, anomaly thresholds and reversibility remain local. Running behavior matters more than an architecture label. The party bearing fraud, privacy and availability loss must retain the final authority to admit, observe, stop and reverse the action.

Sources