Frontend Bff Boundary Review

Frontend BFF Boundary Review

Purpose

Decide whether a multi-backend data need belongs in a Backend-for-Frontend (BFF) route or in client-side composition, and audit an existing BFF layer for the two failure modes that matter most: organic scope creep (duplicated or one-off aggregation logic scattered across routes) and trust-boundary erosion (a BFF that forwards client-supplied authorization claims or credentials without re-verifying them, or that leaks internal backend topology into its responses). This skill exists so the boundary decision and the trust-boundary audit stay the focus, and so field-level contract review of an already-scoped endpoint, or client-side cache/store design once data has landed in the browser, stay out of scope.

When to use

Use this skill when the user asks to:

• decide whether a feature needing data from multiple backend services should aggregate server-side (a BFF route) or client-side (parallel query-library calls),
• audit an existing BFF layer, or a specific BFF route, that has grown organically over time,
• review whether a proposed new BFF route or service duplicates an existing one's aggregation logic,
• check whether a BFF route re-authenticates/re-authorizes the caller or merely passes through client-supplied claims/tokens to backend services.

Do not use this skill for:

• reviewing the field-level shape, versioning, or authorization contract of a single already-scoped API endpoint — that is api-integration-contract-review,
• client-side cache/store design (query-library cache keys, state colocation) once data has already been fetched — that is state-management-decision-review,
• rendering-mode or fetch() cache-directive selection for a Next.js route with no cross-service aggregation involved — that is nextjs-rendering-caching-review,
• Server Action authorization or 'use client'/'use server' boundary review with no BFF-scope question involved — that is nextjs-app-router-data-fetching-review.

Context7 Documentation Protocol

• Resolve /vercel/next.js with resolve-library-id before citing any Route Handler capability, caching directive, or runtime behavior as grounds for a BFF-vs-client-composition recommendation.
• Before recommending a Next.js Route Handler as the BFF implementation vehicle, read the repo's package.json to confirm the installed Next.js major version, then call query-docs scoped to that version for "Route Handler caching" and "route segment config revalidate fetchCache." Caching semantics changed materially across major versions — Route Handler GET methods are cached by default through Next.js 14 but are not cached by default starting in Next.js 15, requiring an explicit export const dynamic = 'force-static' to opt back in. A BFF route assumed to cache aggregated responses on an unverified version can silently hit every backend on every request instead of reducing round-trips as intended.
• If the version cannot be confirmed, or Context7 is unavailable, state the caching claim as documentation-based, version-unconfirmed and recommend the user verify export const dynamic / export const revalidate / export const fetchCache behavior against their installed version before relying on it for load-reduction claims.
• Do not assume a Route Handler behaves like a fetch() call inside a Server Component; segment-level config (dynamic, revalidate, fetchCache) governs the Route Handler's own caching, and it is set independently of caching used for calls the handler itself makes.

Lean operating rules

• A BFF is a trust boundary, not a convenience layer for reshaping JSON. The default posture for any BFF route is that it terminates the client's authentication context and establishes its own — it does not relay whatever the client sent forward.
• Default toward BFF aggregation when a feature needs data from two or more backend services with different authorization models or error shapes. Default toward client-side composition only when the backends involved are already safe to call directly from the browser (same trust level as the client, already CORS-exposed, no internal-only topology).
• Before proposing a new BFF route, search for an existing route already serving an overlapping need. A second BFF route re-implementing the same aggregation is a maintenance and drift risk, not a fresh feature.
• Treat any BFF route that reads a client-supplied authorization claim (a role, user ID, or permission flag taken from a request body, query string, or an unverified header) and uses it directly to gate a backend call as a HIGH-severity finding — this is pass-through authorization, not delegation.
• Treat any BFF route that forwards a client-supplied bearer token or credential straight to a downstream backend, in place of the BFF re-authenticating the session and minting its own downstream credential, as a HIGH-severity finding, unless the system is an explicit, documented token-exchange/delegation design (e.g. OAuth token exchange) with its own re-verification step.
• Treat any BFF response that exposes internal-only backend hostnames, service names, stack traces, or service-specific error codes/shapes verbatim to the browser as a MEDIUM-to-HIGH finding depending on sensitivity — the BFF exists in part to prevent this leak, and a thin pass-through response defeats that purpose.
• Do not recommend client-side composition when it would require the browser to hold credentials for, or make direct network calls to, a backend that is not already intended to be internet-reachable — that is a bigger security regression than the aggregation-placement question being asked.
• Do not flag every multi-call client-side data-fetching pattern as a problem. Client-side composition of two or three already-public, already-authorized endpoints is a legitimate, lower-latency choice; only escalate when trust boundaries or topology are actually crossed.
• Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
• Treat any hardcoded API key, service token, or credential found in BFF route source, environment file references, or example data as a HIGH-severity finding requiring immediate escalation, separate from the boundary-scope verdict.

References

Load these only when needed:

• Review workflow and findings contract — use for the step-by-step boundary-decision procedure, the existing-BFF audit method, and the required output shape.
• OWASP API Security — trust-boundary risks — load only when a pass-through-authorization or topology-leak finding is present, to ground the finding's OWASP API Security Top 10 classification and severity framing.

Response minimum

Return, at minimum:

• the boundary decision (BFF aggregation vs. client-side composition) with justification tied to the number of backends, their auth models, and their reachability from the browser,
• for any new/extended BFF route: an explicit scope statement and a check for an existing overlapping route,
• a trust-boundary audit result (pass-through-authorization check, credential-forwarding check, topology-leak check) for any BFF route in scope,
• ranked findings with file:line evidence, risk class, and fix,
• the Next.js major version the caching claims were verified against, if a Route Handler is the proposed implementation,
• verdict: approve / approve-with-notes / block,
• evidence level and open questions.