When does a backend for frontend make more sense than direct client-to-API access?

Why This Matters for Security Teams

A backend for frontend, or BFF, is not just an architectural preference. It is a custody model for secrets, tokens, and authorisation decisions. When a browser, mobile app, or desktop client talks directly to an API, the client must hold something valuable long enough to be abused. That changes the risk from “can the app call the API?” to “what happens when the app, its storage, or its network path is compromised?” Current guidance from the OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs both point to the same operational reality: public clients are poor places to park long-lived secrets. That is especially true when the key unlocks billing, admin actions, or sensitive datasets.

Security teams also underestimate how quickly direct client-to-API access expands blast radius. A leaked token from a public client is not a small credential hygiene problem if it can trigger financial transactions, modify records, or expose regulated data. The point of a BFF is to place those decisions behind a controlled server-side layer where policy, logging, throttling, and revocation are enforceable. In practice, many security teams encounter this only after a token leak, misuse of a mobile build, or a third-party SDK incident has already exposed the weakness.

How It Works in Practice

A BFF sits between the public client and downstream APIs, so the client never needs direct access to high-value backend credentials. Instead, the client authenticates to the BFF, and the BFF exchanges that session for scoped API calls, often using short-lived tokens, server-side secrets, or workload credentials. That pattern is closer to 52 NHI Breaches Analysis findings than many teams expect: the breach path is often not a sophisticated exploit, but an overexposed identity with too much standing access.

In practical terms, a good BFF design usually includes:

• server-side custody of api key, certificates, and refresh tokens
• request-level authorisation before calling downstream services
• token exchange or session bridging rather than direct secret distribution
• rate limiting, audit logging, and abuse detection at the BFF boundary
• separate policies for read, write, admin, and payment-like actions

This is also where OWASP Non-Human Identity Top 10 guidance becomes operationally useful: the BFF is the place to reduce secret sprawl, narrow token scope, and eliminate direct exposure of credentials in code or client storage. For teams building around third-party APIs, the Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that excessive privilege and poor rotation are still the most common failure modes. These controls tend to break down when the client must operate offline for long periods, because cached credentials then become durable attack material.

Common Variations and Edge Cases

Tighter server-side custody often increases latency, implementation effort, and operational complexity, so organisations must balance user experience against reduced exposure. That tradeoff is most visible in mobile apps, offline-first workflows, and high-frequency consumer interfaces where every extra network hop matters. Best practice is evolving here, and there is no universal standard for when a direct client token is acceptable versus when a BFF is mandatory.

Some environments can justify direct client-to-API access, but only when the risk is low and the token is tightly scoped, short-lived, and revocable. Even then, the decision should reflect the consequences of misuse, not just convenience. A BFF becomes more compelling when intent must be checked at runtime, when different calls require different trust levels, or when the downstream API is too sensitive to expose to a public client. That is why many teams use a BFF for writes, payments, administrative functions, or data exports, while allowing limited direct access only for low-risk read operations.

One useful rule of thumb is that if a stolen token would let an attacker move money, change permissions, or reach protected records, direct client access is usually too much trust. The moment the application needs centralised control over authorisation, secret rotation, or abuse monitoring, the BFF is no longer optional architecture, it is part of the security boundary.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• When does just-in-time access make more sense than permanent admin rights?
• When does just-in-time access make more sense than standing access?