An API gateway handles shared infrastructure concerns such as authentication, rate limiting, and traffic entry for many clients. A BFF is specific to one frontend and focuses on session handling, data shaping, and privileged API calls for that client, which makes it the better place to isolate secrets.
What a BFF does that an API gateway does not
An API gateway is the shared front door for a set of clients, so it is usually where you centralise cross-cutting controls such as authentication, rate limits, routing, and coarse traffic policy. A BFF is narrower: it serves one frontend, so it can translate data into the shape that interface needs and make client-specific decisions without forcing every consumer into the same contract.
That split matters because the gateway optimises reuse and uniform control, while the BFF optimises experience and client fit. When teams blur the two, they often either overload the gateway with presentation logic or make every frontend do its own backend orchestration, which weakens consistency and increases maintenance.
For API security context, a gateway is usually the better place for shared request policy and entry-point enforcement, while a BFF is the better place to tailor responses and isolate frontend-specific calls. NHIMG’s API Gateway Security Guide is useful when you want the gateway-side control model, and API Security Guide helps anchor the broader API security implications behind that design choice.
Why a BFF is often the safer place for client-specific shaping
The strongest architectural reason to use a BFF is boundary control. The frontend usually needs a narrower, more opinionated view of backend data, and a BFF can enforce that without exposing internal API structure directly to the browser or mobile app. That reduces accidental overexposure and keeps client-specific aggregation out of shared infrastructure.
A BFF also makes it easier to separate privileged operations from generic request handling. If one frontend needs a special API call, a BFF can broker that call with tighter context and narrower exposure than a shared gateway path would usually allow. That is also why BFFs are commonly the better place to keep frontend-specific tokens, sessions, or delegated access logic away from other consumers.
A gateway can still enforce authentication and coarse authorization consistently, but it should not become a dumping ground for per-application transformation rules. Once the gateway starts deciding how each UI should behave, it stops being a clean traffic-control layer and becomes a brittle application hub.
Where shared API policy is the real concern, OWASP API Security Top 10 is a strong external reference for the kinds of failures that belong at the shared boundary, especially broken authorisation and API abuse patterns.
How to choose between them in practice
If the decision is about protecting many clients with one consistent control plane, choose an API gateway. If the decision is about one frontend needing a different shape, different orchestration, or different call sequence, choose a BFF. Most mature systems use both, with the gateway in front of one or more BFFs.
The practical test is whether the logic is shared or presentation-specific. Shared concerns belong in the gateway because they should be applied once and enforced uniformly. Frontend-specific concerns belong in the BFF because they are tied to one user experience, one device class, or one consumer contract. If you find yourself adding special cases for a single app inside the gateway, that is usually a sign the boundary is wrong.
Teams also need to watch for overlap. A gateway should not duplicate business shaping logic, and a BFF should not recreate every security control the gateway already provides. The clean pattern is layered responsibility: gateway first for common protection, BFF second for consumer adaptation.
API Security Buyer's Guide is helpful when you need to think about whether a control belongs in the gateway layer, in a BFF, or in a dedicated API security capability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | BFF and gateway boundaries affect who can invoke privileged API functions. |
| Recommendation — Enforce function-level authorization at the shared API boundary before exposing privileged operations. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The gateway commonly centralizes authentication for shared client entry. |
| IA-5 — Authenticator Management | BFFs often handle client-specific tokens and secrets that need tighter lifecycle control. | |
| AC-6 — Least Privilege | A BFF should broker only the access each frontend needs, limiting blast radius. | |
| Recommendation — Centralize user authentication at the shared entry point before traffic reaches backend services. Manage frontend-specific credentials and tokens with strict issuance, rotation, and revocation. Limit each frontend flow to the minimum backend permissions required for that client. | ||
| OWASP ASVS | V8 — Authorization | API gateways and BFFs both enforce access decisions that affect exposed operations. |
| Recommendation — Verify that both shared and client-specific access decisions are enforced explicitly, not implicitly. | ||
Practitioner Guidance
What to verify: Confirm whether each backend call is genuinely shared across consumers or only exists to satisfy one frontend. Shared controls belong upstream, but client-specific payload shaping, session context, and privileged fan-out calls are usually BFF responsibilities.
Decision rule: If moving logic into the gateway would force every client to inherit a frontend-specific rule, keep it out of the gateway. If moving it into the BFF would duplicate an organisation-wide control, keep that control at the gateway and let the BFF consume the protected service.
Common mistake: Treating the gateway as an all-purpose mediation layer. That often creates hidden coupling, makes change management harder, and obscures where authentication, authorisation, and response shaping are actually happening.
Practitioner takeaway: Use the gateway for uniform entry-point enforcement and the BFF for per-frontend adaptation; the design is healthy when each layer does one job clearly, and risky when either layer starts compensating for the other.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org