SaaS Application Security Guide: Issues, Best Practices, and Examples

The relative simplicity and affordability of cloud software development can sometimes overshadow security concerns. 

Don’t fall into the same trap. 

200+ companies from 25 countries outsourced software development to Relevant

We provide companies with senior tech talent and product development expertise to build world-class software. Let's talk about how we can help you.

Contact us

Whether you’re ditching on-premises software for a SaaS offering or scaling up a cloud-based business, security should be high on your list of priorities, not an afterthought.

Look at it this way: the rising demand for SaaS has brought with it an increase in security threats. One particularly high-profile cyberattack was the 2017 Equifax data breach, which compromised the personal information of 143 million people—more than 40% of the US population.

Equifax’s massive security breach exposed sensitive data like addresses, social security numbers, and credit card numbers. Security flaws that began with a vulnerability in a web portal allowed attackers to enter the system, infiltrate servers, and steal data. 

As a software developer or business owner, what can you do to prevent this from happening to you? 

The answer lies in taking stock of SaaS security best practices. From arming yourself with a security checklist to choosing the right isolation scheme, this article will help you safeguard your business against a SaaS security breach. 

SaaS security issues

Before you can fend off attackers, it helps to know where they’re coming from. 

One valuable resource for this is the OWASP Top 10. Established by the Open Web Application Security Project (OWASP), the list ranks the top 10 most critical security risks in software, based on community submissions. A product of the combined efforts of security experts from around the world, the list ranks the risks based on how often the security defects are discovered, the extent of the vulnerabilities they expose, and their potential impact.  

Getting familiar with the OWASP Top 10 will make you aware of the most common SaaS security risks your application could face. You can use this to develop practices to minimize such risks in your product.  

Here’s a summary of the OWASP Top 10 to get you started. You can find more information about each risk type on the OWASP website.

Injection

Attackers can send injection codes or invalid data into a web application, making it do something it’s not supposed to do. 

Broken authentication

Incorrectly implementing the authentication and session management functions can compromise passwords, session tokens, or keywords. Attackers can use these flaws to steal users’ identities. 

Sensitive data exposure

Attackers can steal weakly protected sensitive data such as personally identifiable information (PII) and social security numbers and use them for crimes like identity theft and credit card fraud.

XML external entities (XXE)

Attackers can target applications with vulnerable XML processors by including hostile commands within an XML document.

Broken access control

Improper enforcement of access restrictions gives attackers the opportunity to operate as an administrator or authenticated user, modify access rights and user information, and view files.

Security misconfiguration

This security issue results from a configuration shortcoming or error in the operating system, middleware, or database. For instance, a default account and original password that are still active can leave the system vulnerable to attacks.

Cross-site scripting (XSS)

Attackers can use code flaws or specially constructed data in an application to inject scripts into a webpage, which allows them to gain access to the victim’s browser, hijack user sessions, and redirect them to malicious sites.

Insecure deserialization

Attackers can use deserialization flaws to remotely execute code, inject scripts, replay attacks, and gain privileged access to restricted resources.

Using components with known vulnerabilities

Afforded the same privileges as the application, vulnerable components can undermine defenses and enable attacks that can lead to server takeover and data loss.

Insufficient logging and monitoring

Failure to adequately and frequently log and monitor application activity can allow attackers to intensify their activities, steal or destroy data, and pivot to more systems.

If this long list of cloud application security risks seems daunting, take heart. The following simplified security checklist will help ease you into the process of securing your SaaS offering.

SaaS security checklist with general security recommendations

Proper cloud security assessment will help you identify your application’s vulnerabilities. With this knowledge, you can adopt solutions that shield your application from risks. 

A good place to start your assessment is with a SaaS security review checklist. This will help you make sure all your employees are properly informed of the security measures they are expected to follow.  

Here’s an example of the different areas you need to consider, plus their corresponding checkpoints. Any point that’s left unchecked for your project or organization shows a potential security weakness you should consider addressing.

Employees

• Employees are on the same page concerning the recommended security practices
• The sharing of user accounts is prohibited
• Assets like phones and laptops are encrypted
• Two-factor authentication and the use of password managers are being enforced
• User logins are being monitored
• Dedicated or partially dedicated security engineers are available to handle crucial security tasks

Coding

• A Secure Development Lifecycle (SDL) is being used
• Security within the Software Development Life Cycle (SDLC) is automated
• A secure code review checklist is being enforced
• Security-oriented test sessions are being performed
• The coding environment integrates identity and access management (IAM) and account provisioning systems
• The project includes event and log notifications
• The project includes fault-tolerance and scalability

Application security vulnerabilities

• The testing environment covers the following types of vulnerability:
  • Information gathering vulnerabilities
  • Configuration management vulnerabilities
  • Authentication and authorization vulnerabilities
  • Data validation vulnerabilities

Application

• Security is automated 
• Real-time protection services are being used
• Dependencies are being tracked
• The application supports Security Assertion Markup Language (SAML)
• Application support includes System for Cross-domain Identity Management (SCIM) or Service Provisioning Markup Language (SPML), multi-factor authentication, OAuth, and more
• A desktop client is available for data synchronization
• The application supports automated identity importing 
• The application supports authentication filtering

Infrastructure

• Backups are carried out and tested
• The application’s underlying security is in place
• Internal services are being monitored
• Exposed services are being monitored
• Applications and APIs use encryption

Organization

• A cohesive security culture is in place
• There’s transparency in data collection
• An inventory of the assets exists
• A public security policy is in place
• The organization has a security incident response plan
• The organization uses tools that prioritize security
• Protection from vishing and phishing is in place
• The organization ensures compliance with legal requirements and organizational policy
• There’s support for disaster recovery and business continuity

Application users

• The use of two-factor authentication is being encouraged
• A password policy is being enforced
• Suspicious activities are being monitored

SaaS service provider

• SLA uptime is acceptable
• The company provides phone support and the status of the web-based console reporting infrastructure
• The provider has the necessary security compliance certifications
• The physical location of the disaster recovery site (DR site) is in order
• Data over the internal network is properly encrypted
• The provider is handling personally identifiable information (PII) properly and responsibly
• Administrators have limited access to customer data
• The provider’s application is using your preferred architecture (either single-tenant or multi-tenant)

This SaaS security checklist does a great job of ensuring everyone in your organization is well aware of your security requirements. You can take your efforts a step further by providing your employees with SaaS cybersecurity training to help prevent common hacks such as social engineering, phishing, and vishing. 

Actively promoting a cohesive security culture will encourage the rise of security champions or people who actively promote security in your organization. But it shouldn’t stop there.

Your security training efforts should also extend to your customers. Provide them with the education they need to prevent account takeover fraud (ATOs) or situations where hackers could steal their identity and control their account. Precautionary measures can be as simple as enforcing two-factor authentication and encouraging the use of password managers. 

Validate role-based access limits on cross-tenant access

There’s a good chance your service uses a multi-tenant server solution, where a single software instance and its infrastructure can be set to serve multiple customers. Multi-tenancy is simple and affordable, which makes it popular with cloud users.

Although a much less secure option than single-tenancy, the collaborative environment of multi-tenancy allows customers to divide some of the costs among themselves. This makes for an easier startup experience, fewer hardware requirements, and lower maintenance expenses.

Unfortunately, there are downsides to this solution too. If you’re using a multi-tenant architecture for your SaaS, a real security concern is the mingling of data and user activities in the collaborative environment. You can mitigate this risk by ensuring your system uses an access control model that protects sensitive information for every collaborator, namely a multi-tenancy authorization system.

Traditional and more commonly used role-based access control (RBAC) allows for fine-grained access control mechanisms but falls short when it comes to managing the kind of collaboration in a multi-tenant setup. To facilitate collaborations among cloud services, a multi-tenancy authorization system (MTAS) builds on RBAC with a coarse-grained trust relation. 

Abstracted from the MTAS system, the MTAS model has four entity components: issuers (I), users (U), permissions (P), and roles (R).

An issuer is an individual or organization that uses the cloud services. Put simply, they are the service provider’s clients. A service designates a tenant or an interface for each issuer, ensuring that their respective actions and data are isolated from each other. 

A user represents an individual or a process. An owning issuer provides a unique identity and authentication to every user, in the form of a federated ID. 

Specified as a service interface, a permission assigns a privilege to a tenant. The permission’s tenant attribute belongs to a single issuer. 

A role refers to a job function with an issuer. It belongs to only one issuer.

A session represents a user’s instance of activity. The user’s subset of roles can be activated in a session. In a multi-tenant cloud environment, the user and active roles may not all come from the same issuer.

Validate tenant isolation schemes

A further step in ensuring the security of your database in a multi-tenant architecture is determining how your service provider is preventing tenants from accessing the resources of other tenants. Any unwanted boundary breach can result in an event or security issue that may prove detrimental to your business. 

There are many ways to approach SaaS security concerns related to tenant isolation. Two key strategies are the silo model and the pool model.

In a silo isolation model, resources are fully isolated from other resources. The tenants do not share them in any way. 

Another way to approach isolation is through the pool model. In this arrangement, tenants share resources in a unified environment. Isolation is achieved through fine-grained mechanisms such as authentication policies.

Storage isolation patterns

A simple way to approach isolation is by starting with storage. A silo storage model may involve a separate database per tenant, with policies stating that one tenant cannot cross the boundary to another tenant’s database. A pool storage model, on the other hand, may involve shared constructs, with policies stating that a tenant can only see rows or items that belong to them.

Which approach to isolation is best for you? It’s a question of weighing up the options.

The silo model offers straightforward and clearly defined partitions that are compelling for customers who are compliance- and security-focused. It’s easier to implement and has better alignment with the stack of tools provided by leading cloud service providers. Still, the silo model comes with all the challenges of a decentralized system, such as less than ideal deployment, cost optimization, manageability, and account limits.

Policy-based isolation, on the other hand, allows for a fine-grained control of resources. Because you’re sharing resources with tenants, you get to cut costs. The challenge comes with convincing your customers to buy into what appears to be a much more complex model. Also, your developers will have to deal with a mix of technologies. 

Most organizations end up using a hybrid of these isolation models. You can draw on the strengths of a silo model for some of your stacks and rely on policy-based isolation for others. It all boils down to taking a closer look at what your customers want and delivering the best value.

How to know if your isolation model is working

It’s not enough that you’ve built an isolation model: you have to make sure it’s actually working. You can do this by creating testing environments that catch issues before they become a problem in the real world. 

For example, you can inject a tenant and purposefully try to cross the boundary of another tenant by attempting to access their restricted data. You know your isolation model is working if you’re unable to breach the boundary.

Assess data security in SaaS 

Aside from server hosting, another key area of focus when assessing the security of your SaaS application is data. 

Entrusted with sensitive data like credit card information, cloud-based software can expose your business to serious data breaches, legal problems, and financial liabilities. To secure your data, make sure the following practices are on the top of your list of priorities. 

Stay compliant with certifications and audits

Certifications like the Payment Card Industry Data Security Standard (PCI DSS) help ensure that a company is adequately protecting sensitive data. To comply with PCI DSS, SaaS providers have to conduct thorough audits to ensure sensitive data is securely transmitted, processed, and stored.

Another essential certification is the System and Organization Controls (SOC 2) Type II. This certification ensures that your cloud service maintains high-security controls to protect data. 

Enforce data retention

Some data are required by law to be retained for a specific period of time. Examples include names, addresses, financial records, and social security numbers.

You’re also legally obliged to delete this data when you no longer need it. Deadlines for the deletion of the data vary depending on your reasons for processing them. Penalties for noncompliance can come in the form of exorbitant fines and reputational damage.

You need to have a clear understanding of which data needs to be retained. This will help create and streamline backups and free up space, and also help you stay compliant. 

Implement transmission data encryption

Encryption lets you shield data against unauthorized users by reinforcing data confidentiality and authentication. Even if unauthorized users are able to break through security barriers, they won’t be able to harvest your data without encryption keys. To ensure encryption during transmission, you should make sure all communication between applications and the servers is facilitated by the Transport Layer Security (TLS) protocol. 

Don’t forget that data in storage needs just as much protection as your data in transit. Field-level encryption lets you ensure your data is both securely transmitted and stored.   

Integrate real-time protection

Real-time monitoring uses protection logic to distinguish malicious attacks from legitimate queries. It enables early detection and mitigation of SaaS application security risks. 

Integrating real-time monitoring into your custom SaaS application results in improved visibility, compliance, control, and policy management.

Summary

From greater scalability and ease of integration to reduced costs and increased accessibility, SaaS comes with benefits that balance out its higher exposure to security risks. The payoff is that you can’t take security concerns lightly. 

You can start protecting your SaaS by learning more about the most common risks, then reviewing your setup using a comprehensive checklist. Follow this up with an understanding of multi-tenancy, isolation schemes, and data protection, and you’re on your way to avoiding costly security mistakes and violations.

Are you ready to improve your SaaS security?

Cloud security is a big responsibility. Working with Relevant means entrusting experts and seasoned professionals with the task of securing your data.

85% of Relevant’s team is made up of middle and senior specialists with advanced degrees. We put security first by deploying security measures in advance to preempt data leaks. Our versatile approach means you get the solution that best matches your business challenges.

We’d love to dig deep into your business profile to learn about your SaaS security needs. Let’s talk!