Performance

• A BFF API has the capability to consolidate multiple API requests to downstream backend services, thereby reducing the number of round trips needed.

• Reduce the response payload size from downstream services.

Security

• Redact or remove sensitive payload from downstream services.

Functionality

• BFF is potentially the best place to implement server push or notifications (such as WebSockets).

• BFF is the service to store frontend states, which do not make sense for downstream services, for instances:

  • Which page the user is currently working on.

  • Partially filled form data.

• BFF can host client specific logic that doesn’t make sense in downstream resource oriented services.

• BFF can host additional assistance frontend focused features, such as

  • Autocomplete

  • Search

Productivity

• Reusability: Centralizing frontend business logics.

  • Devs don’t need to rewrite the same logic for iOS, Android and Web.

  • Consistency in business logic across platforms improves user experience.

  • Even if platforms have to use distinct logics, BFF helps document them as code in the same service.

• Backend-driven rendering. Enables faster experimentation and bypasses slow iOS/Android release cycles.

• Faster iteration and autonomy for the frontend team.

References:

• https://samnewman.io/patterns/architectural/bff/, very good article that shares concerns on further implementation tradeoffs.

• https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends

• Startups with limited resources should avoid spending too much effort on managing infrastructure. Resources should be focused on building products.

• Choose a widely used platform, you do not have time to fix bugs for lesser known platforms.

Choices

1. Website Builders for Simple Services

If your startup doesn't require a dynamic backend or primarily offers simple services, website builders are an excellent choice. Examples:

• Webflow

• Squarespace

2. PaaS/App Engines for Software Applications

If your startup is primarily building software applications to enable your business, and there isn’t notable requirement on infrastructure performance or security. Recommended choices:

• Render

• Heroku

• Google App Engine

3. IaaS with Containerization for Software-Intensive Startups:

If your startup is heavily linked to software infrastructure, cloud or has high security expectations. You will likely need engineers that are somewhat familiar with infrastructure at this company in this case. Recommended choices:

• AWS EKS

• AWS ECS

• GCP GKE

AWS ECS vs. Kubernetes (EKS, GKE)

• ECS: Although not as popular as Kubernetes, ECS boasts advantages in maintainability and stability. AWS handles ECS's control plane upgrades, making cluster maintenance simpler compared to Kubernetes.

• Kubernetes: Widely adopted by the open-source community, Kubernetes offers configuration flexibility and supports various open-source applications via Helm charts. However, it requires more attention to version upgrades.

• Conclusion: If you prefer less infrastructure maintenance and version upgrades, choose ECS. If you prefer configuration flexibility and may install lots of open source tools to work on your applications, then Kubernetes might be a good choice. The flip side is that you may need to take care of the k8s version upgrades from time to time.

Notable bad choices

• AWS Elastic Beanstalk: The worst app engine platform.

• Lesser used container platforms: Openshift, Docker Swarm etc.

• Run your application on one VM.

• Deploy your own instances that’s not using a containerization platform.

Ending Note: This blog is served as a general guidance. Your situation may be unique.

Measures against Credential Stuffing could be categorized into:

• Remove usage of passwords (Best)

• Add friction to login in addition to passwords (Second best)

• Slow down automated login attempts (Easy, but not so useful)

Here is a list of countermeasures in the order of preference.

1. Replace password login with password-less login.

   • Difficulty: 🔧🔧🔧 (client, server-side changes)

   • Effectiveness: 🌟🌟🌟🌟🌟 best solution, completely solves the problem

   • Comment: If password is no longer accepted, credential stuffing attack no longer works. Password-less login is relatively easy to implement.

   • Considerations:

     • Password-less login requires client changes. Mobile client changes will require a force client upgrade.

     • Email/Social login is preferred. Phone SMS login causes other issue because phone number could be rotated.

     • Remember to remove password login API endpoint.

2. Implement multi-factor authentication

   • Difficulty: 🔧🔧🔧🔧🔧 (client, server-side changes)

   • Effectiveness: 🌟🌟🌟🌟 greatly reduced risks

   • Comment: 2FA denies attacker the access to sensitive info with password only.

   • Considerations:

     • 2FA adds friction to user experience. Consider using adaptive MFA (only prompt if new device or location) to reduce friction if possible. Or only require 2FA for sensitive activities.

     • 2FA implementation may also require client-side change. 2FA adds a lot of logic into the login process, it’s difficult to get right (handle the situation where your second factor is lost, for example).

3. Deny usage of leaked passwords

   • Difficulty: 🔧🔧 (server-side changes only)

   • Effectiveness: 🌟🌟🌟 the solution is only as good as your password list

   • Comment: Collect a list of leaked passwords and reject passwords on the list. This could use the help of a bloom filter.

4. Implement CAPTCHA to slow down automation

   • Difficulty: 🔧🔧🔧🔧 (client, server-side changes)

   • Effectiveness: 🌟🌟🌟 denies automation but manual attack is still possible

   • Comment: CAPTCHA makes automated validation of passwords more difficult.

   • Considerations:

     • CAPTCHA implementation requires client-side changes.

     • CAPTCHA only makes the automated attacks manual or difficult to automate.

5. Rate limit, IP-based blocking or risk-score based blocking of attempts.

   • Difficulty: 🔧 (server-side changes only)

   • Effectiveness: 🌟 easy to bypass

   • Comment: Setting up rule-based blocking or rate-limit is simple. However it’s also not difficult to by-pass with the use of proxies. Determined attacker can find ways around within days. It’s a cat-and-mouse game.

6. Strong password policies

   • Difficulty: 🔧 (server-side changes only)

   • Effectiveness: 🌟 barely helps

   • Comment: Strong passwords also get leaked on other websites.

Honorable mentions of detective measures:

• Notifying user with new logins.

• System monitoring of abnormal login attempts.

Conclusion

A number of common measures against Credential Stuffing attacks are discussed here. The best solution is to completely remove the usage of passwords. If removing password isn’t possible, a combination of measures could be implemented. Server-side only measures are easy to implement but usually less effective. Measures involving client-side changes, however, alter the user flow and takes a longer time to implement.

Dangerous Overemphasis on “Micro“

You may have seen examples of overly-micro services in an organization near you. Another engineer may blindly implement the concept of "microservices" without fully understanding the implications. This could lead to unforeseen issues.

Sideeffects caused by extremely micro services include:

• System load overhead. More services mean more connections between services, fewer resources being shared.

• Management overhead. Unifying system configurations for huge amount of services is a daunting task, especially for those organizations that don’t have a thousand-people infra team like Google.

• Increased cognitive load. Workload for documentation and onboarding is increased.

• Increased complexity leading to outages. Complex systems pose greater challenges for troubleshooting and increase the likelihood of cascading failures.

• Weird career incentives. Some engineers see creating a new service as a way to get a better performance rated or promoted.

When it’s OK to be Slightly More “Micro”

My advice for startups is always: start with monolith, break apart when necessary. Valid reasons to break apart monolithic include but not limited to:

• The components are owned by functionally separate teams. Break apart application to increase development velocity.

• The components have different performance profiles. Some components autoscales more rapidly than some other components. They may need to be written in different programming languages to improve performance.

• The components should be located in separate locations. For example, public facing vs in a private subnet.

• The components have different deployment schedules or risk profiles.

What to Replace the Term with

“Service-Oriented Architecture (SOA)”

When referring to a system architecture style that’s loosely coupled, SOA is much more specific and delivers clearer meaning.

“Service”

When referring to the individual application itself, “service” is usually sufficient to convey the message. You can break apart a monolithic application into two services, which are not necessarily “microservice”.

Conclusion

Decomposing a monolithic application isn’t always right or wrong, it’s dependent on the situation. The term "microservice" has become a vague buzzword that can lead to hasty implementation with unintended consequences. You have the choice of using terms with clearer definitions.

Compared to other social login methods, Google Sign-In has clear advantages:

• Facebook Login. Facebook is usually not accepted by SaaS software. I am also concerned about friend list exports. Maybe you are not granting the permission, but your friend may give the 3rd party site about the connection.

• Sign in with Apple. Limited adoption and web experience.

• Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, etc. Limited adoption.

In addition, Google Sign-In provides a superior sign-up and login experience, reduces friction and potentially increases conversion. In many cases, either for SaaS applications or consumer-facing applications, implementing Google Sign-In would be a good idea for your business.

The following content describes common security considerations we came across when integrating Google Sign-In.

Gmail Address Normalization

An open secret about Gmail accounts is that each account has many aliases. For example, the following email addresses are considered the same account on Google:

• j.o.h.n.d.o.e@gmail.com

• johndoe@gmail.com

• JOHNDOE@gmail.com

• johndoe+123@gmail.com

• johndoe@googlemail.com

If your web application has not already normalized Gmail addresses. It may be a good idea to normalize them before implementing Google Sign-In. It affects the way how existing email-identified accounts will be merged with the new login method.

Incorrect Interaction with Password Login

An attack scenario for account takeover could happen if the web application allows email-password sign up without email verification.

• The victim isn’t a user of your web app. Attacker creates an account using the victim's email johndoe@gmail.com, and a password. The account email confirmation isn't yet activated.

• The victim johndoe@gmail.com then signs up again using Google Sign-In. The victim put their information into the account.

• The attacker may be able to log in using the password they created. The Attacker now may view the victim’s personal information.

There are a few possible ways to avoid the takeover vulnerability.

• Disable password login once Google Sign-In is linked to the account.

• Reset password once Google Sign-In is linked to the account.

  • Email confirmation completed cases: send a "security alert" telling the user that the existing account is linked with Google Sign-In.

  • Email confirmation incomplete cases: revoke existing password associated with the account, send a "security alert" to tell the user that their password is reset due to Sign-In. The user needs to go through the password reset flow if they want to use a password again.

Verification of Authentication Tokens

Google has provided guidance on verification of their “id token” returned by the sign-in process. However the backend server may have a faulty implementation that leads to security issues. Common cases of problem:

• Lack of verification of client_id in token. Attacker uses a token from another phishing app they created.

• Lack of verification of user_id (sub) in token. Your mobile/web app could pass a user_id alongside with the oauth2 token optimistically, but no verification of these two matching.

• Lack of verification of the "email_verified" field. Not sure if this is really exploitable, but I hope the field should always be true.

• Lack of checking expiration of the token.

To reduce potential mistakes, it’s recommended to use well-known verification libraries, especially those that are designed specifically for Google Sign-In.

Sign In With Apple Implementation May be Required

According to App Store Review Guidelines, if you have any social login method integrated, the app needs to offer “Sign in with Apple” to get app review passed on iOS. As the guideline text says:

Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.

This requirement adds to the complexity of integration. Especially with Apple’s Hide My Email functionality. Your application may need to consider situations where your application may not receive the users’ primary email addresses.