This article compares the security architecture of an application implemented using a public UI SPA with a trusted API backend and the same solution implemented using the backend for frontend (BFF) security architecture. The main difference is that the first solution is separated into two applications, implemented and deployed as two where as the second application is a single deployment and secured as a single application. The BFF has less risks and is a better security architecture but as always, no solution is perfect.
Setup SPA with public API
Advantages using BFF
- Single trusted application instead of two apps, public untrusted UI + public trusted API (reduced attack surface)
- Trusted client protected with a secret or certificate
- No access/reference tokens in the browser
- No refresh token in the browser
- Web sockets security improved (SignalR), no access/reference token in the URL
- Backchannel logout, SSO logout possible
- Improved CSP and security headers (can use dynamic data and block all other domains) => possible for better protection against XSS (depends on UI tech stack)
- Can use MTLS, OIDC FAPI, client binding for all downstream API calls from trusted UI app, so much improved security possible for the downstream API calls.
- No architecture requirement for public APIs outside same domain, downstream APIs can be deployed in a private trusted zone.
- Easier to build, deploy (my experience so far), Easier for me means reduced costs.
- Reduced maintenance due to reduced complexity. (This is my experience so far)
Disadvantages using BFF
- Downstream APIs require redirect or second API call (YARP, OBO, •OAuth2 Resource Owner Credentials Flow, certificate auth )
- PWA support not out of the box
- Performance worse if downstream APIs required (i.e an API call not on the same domain)
- All UI API POST, DELETE, PATCH, PUT HTTP requests must use anti-forgery token or force CORS preflight as well as same site protection.
- Cookies are hard to invalidate, requires extra logic (Is this required for a secure HTTP only same site cookie? low risk)
I have had some excellent discussions on this topic and very valid points and arguments against some of points above. I would recommend reading these (link below) to get a bigger picture. Thanks kevin_chalet for the great feedback and comments.
A lot of opinions exist with this setup and I am sure lots of people see this in a different way with very valid points. Others are following software tech religions which prevents them accessing, evaluating different solution architectures. Nothing is ever black or white. No one solution is best for everything and all solutions have problems, or future problems with any setup will always happen. I believe using the BFF architecture, I can increase the security for the solutions with less effort and reduce the security risks and costs, thus creating more value for my clients. I still use SPA with APIs and see this as a valuable and good security solution for some systems. The entry level for BFF architecture with some tech stacks is still very high.