Developing Backend For Front End (BFF) — checklist/best practices

BFF sample architecture wrt Open APIs or traditional MVC apps

So you are making a front end using channels like mobile native app or hybrid app or a web app to let user consume and use data provided by APIs.

You don’t want to break trust of API provider or the user and also don’t want the competitors or third parties to leverage the trust established on you.

In that case, you will be required to safeguard the secrets and data which are shared by API and end user.

The suggested architecture may look like the pic above.

Here are some best practices you should follow while building as per above architecture.

If you are allowing access to your Front End (aka Channel) in an insecure environment (e.g. Web Browser) and user or the man-in-the-middle can access the content and traffic between you and API Gateway or API provider, you should develop a Secure server dedicated to your Front End.

This is called your BFF — Back end For Front End and also Best Friend Forever for your channel ;)

• The (insecure) Front End app must not directly authenticate with the API Gateway to avoid leaking login credentials to user or man-in-the-middle
• Front End app should request for public key, if required, and only can be used to identify itself during specific operations like Open Authentication. No private secrets/key to be shared to Front End app
• Front End app should be on same domain as the BFF, and if possible be provided from same Server , unless you want to serve the FE from its own dedicated server for some good reasons. Browsers don’t forward cookies cross domain and there can be other complications related to security otherwise
• No trickeries should be allowed to establish trust between FE and BFF
• BFF should be unique for each FE (Front End) catering to FE specific needs
• All the Data Transformations, Business Logic or channel specific logic has to be in BFF. FE should have only presentation logic and event handling.
• BFF should be single source of truth for FE, so if multiple APIs/DBs/Files are required to obtain required resources, it should be done by BFF
• FE should have No business logic and should be least coupled with any other layer of the application
• FE should have Only Display and Controller logic to help User achieve best out of the medium she has chosen to consume the data
• BFF should not allow CORS, XSS and other unwanted traffic and potentially insecure requests
• BFF should not disclose underlined technology and file structure (like language/platform/server etc) to consumer apps or users — to achieve better security
• BFF should not allow infinite use of its end points
• BFF has to be load/performance tested
• BFF has to be security scanned along with its dependencies
• FE has to be security scanned along with its dependencies
• BFF should generate its own API, dedicated to the Front End (aka Channel) and not try to be a Generic BFF to cater to other similar Front Ends - e.g. a BFF for mobile app supporting smart watch — should not be allowed as both are different channels and should have dedicated Front End Specific Business Logic served by their own BFFs
• BFF must do Whitelisting if 3rd party integration to other systems is required.
• Blacklisting does NOT work
• FE should avoid data persistence on client side, to always have latest data coming from API.
• An immutable store with minimal complexity can be implemented to take benefits of Single Page Application architecture
• API gateway session details should not be shared on FE. Rather FE should create its own session (if at all stateful) with BFF and BFF should have its own session with API Gateway.
• No insecure/script manipulated Cookies on FE please
• If caching/persistence of user session specific data is required on FE, it should be done on BFF layer and Not on client side. Cache are faster, easy to load-balance, can store huge amount of data, gives better control to application owner, has features like encryption etc. This design also allows continuing user session when FE / user device crashes.
• Consumer app should not take unwanted responsibilities, like authenticating a User on behalf of an authentication server. Rather ask for dedicated Authentication FE + BE and use best practices like Social Login, OAuth, JWT etc.
• Check with API Gateway team if there is already an SDK (for FE and BFF both) for above and insist on using it, rather taking sensitive matters like this in your own hands :)
• Get your FE and BFF penetration-tested by inhouse security expert
• Set KPIs from architect and business perspective and set up Automated health check plus monitoring of FE and BFF to ensure availability and resilience in case of failures.
• Is your FE available outside secure network (like cybercafe or an airport wifi)? You must take extra care to make it more secure and consult an expert for it (e.g. rethink the urls which will reside in browser history)
• Data masking of confidential information like mail id/credit card/phone numbers/hint questions etc should be done on BFF/API layer before it lands on FE. FE data masking can be easily revealed when user has complete control of FE layer or by the man-in-the-middle.
• Each layer should do its own data-validation and not rely on the consuming layer. Hence even when BFF serves a single Front End and FE has done validations, the BFF layer should do required validations and error handling before giving any data to API layer. Also API layer should do its own validations and error handling to avoid the consumers’ mistakes breaking the APIs.
• friendship to be continued…