> TRIPLA SECURITY

How to pick a secure tech stack for your SaaS product

One of the most important things to take into consideration when researching the tech stack for your next SaaS product is the security aspect. Some solutions might be cheaper, but come with greater costs over time. Other might be overwhelming and eat too much of your early stage budget which can slow down your growth.

Recently while browsing the Reddit r/SaaS substack, I noticed a question focusing on exactly this topic:

I’m looking (research stage) into launching a SaaS product similar to Brolly (https://brolly.com.au/), which focuses on social media archiving and compliance. I’m looking for advice on what tech stack to use.

I want to ensure the product is scalable, secure, and efficient (captain obvious). If you have experience in developing similar SaaS applications, I’d love to hear your recommendations. What technologies worked well for you? Are there any specific tools or frameworks that you found particularly useful? Any common pitfalls I should be aware of?

Talking strictly from a security perspective, there are several aspects that you should pay attention to:

Authentication

Often referred to as the login part of the application. I think it’s safe to say to long are gone the days where a quick username/password login form was enough to provide access. Single factor authentication (those that only require a “strong” password) have been proven over and over again that they are insecure due to many reasons: prone to phishing, password reuse, password spraying, bruteforcing, and even SQL injection.

Modern and secure solutions must support one or more of the following:

  • Single Sign-On with platforms such as Okta, MicroSoft, Google, etc.
  • Multi Factor Authentication (using mobile application, but not SMS!)
  • Passwordless Authentication where a unique token is sent to the user’s email on every login
  • Integration with weak/compromised passwords API to alert the user
  • Password Strength Meter

Authorization

Authorization can be easily described as “who has access to what?”

In terms of authorization, you want to pick a framework that gives you the option to easily see/configure access control (such as RBAC – Role Based Access Control). Broken Access Control is the most common vulnerability that gets undetected by automated scanners.

Most of the SaaS platforms follow the same architecture where customers are placed in their own organization (or a tenant) and they get access to an account limited to that scope.

In B2B cases where the SaaS is used by another company, the tenant will have multiple users and most likely an admin to manage them. There are three main types of access control vulnerabilities affecting most SaaS platforms:

  1. Horizontal – horizontal broken access vulnerabilities happen between users that are part of the same organization. A regular user account may be able to access data of another user in the same organization by replacing his UserId with the victim’s one in the HTTP requests sent to the server
  2. Vertical – vertical access vulnerabilities happen when regular users are able to access data or functions which are intended only for admins. This may be called as well a privilege escalation. A common case is when regular users call directly the API endpoints used by admin members and the server fails to impose proper access control
  3. Cross-organizational – just as the name says, these are the types of vulnerabilities where regular users or administrators of one tenant are able to access data of another tenant (company) since both are hosted on the same platform. In terms of impact, cross-organizational access control vulnerabilities can lead to more sever data breaches. A common scenario is malicious actors registering for a SaaS platform and, by exploiting the vulnerability, get access to all companies using the given platform

Data Protection

In terms of data protection, it’s important to consider how is the tech stack that you choose protecting the data from leakages:

  1. Data at rest – does the framework support options to encrypt files stored on disk and in the database?
  2. Data in transit – support for setting up and renewal of SSL certificates to ensure encryption of data between client and server
  3. Data sharing – how are files shared between users or with external parties? How is access reviewed and/or revoked? What 3rd party services (analytics, marketing, email, etc.) have access to the sensitive information?

A “data leakage” is not a vulnerability per se, but rather the outcome of exploiting a weakness in your platform such as:

  • public exposed databases
  • internet access to the admin web portal
  • insecure configuration of the cloud storage (S3 buckets, Azure storate, etc.)
  • API endpoints that return too much information
  • lack (or improper) authentication and authorization

Data leakages can occur as a result of many vulnerabilities caused by:

  • existing bugs in the framework/library that you choose -> lack of patching, using outdated software, picking a framework that doesn’t take security serious
  • misconfigurations -> not understanding how a specific configuration can affect the security of your platform
  • developing insecure code -> lacking knowledge of security best practices of OWASP top 10 common attacks

Conclusion

Overall, no matter the tech stack that you choose, there will be security issues, but you want to pick frameworks/libraries/platforms that push security patches and updates as much as possible instead of hiding/denying them. You can check this by looking at the change log of their previous patches. How often are security patches mentioned in their logs? Do they have a security policy?

Just because a solution has alot of CVEs it doesn’t mean they not secure. These are issues that have been reported and in most cases already fixed. I would be more suspicious about solutions that have very few or even no CVEs at all.

Keep in mind that compliance to a standard (SOC2, GDPR, PCI, etc.) doesn’t necessarily make your application more secure if you don’t combine them with secure coding standards and regular security reviews, scanning and pentesting

The most likely places where your app will be vulnerable is:

  • custom code and features that have been developed by your team especially if they don’t have strong understanding of the OWASP Top 10 and secure coding standards
  • insecure configuration of your app/cloud infrastructure
  • outdated software and lack of patches