We’ve come a long way with the evolution of application architecture. Traditionally, we had applications running on a single server. As days passed, that changed to multiple server architecture, distributed systems, and cloud. And not so long ago, there came a new player to this party - serverless architecture. Serverless applications are applications running on such architecture. Serverless apps help developers focus on building and running applications without scattering their time and attention managing servers. 

Throughout the evolution, one thing that remained constant is the security of these applications running on different architectures. In this article, we’ll focus on securing serverless applications. We’ll understand the need to secure serverless applications, the risks of insecure serverless applications, and some of the best serverless security practices. 

What are Serverless Applications?

Before anything else, the term “serverless” is not to be literally taken. Serverless doesn’t mean there are no servers. There are servers in serverless architecture and applications run on these servers. So why “serverless” if there are servers involved? It’s in the context of what the developers need to manage. And servers are not one of those things. Hence the term serverless. Some common terms related to this concept are serverless computing, serverless infrastructure, and serverless applications. 

Similar to how cloud service providers provided servers for applications, most providers now provide a serverless infrastructure where the developers only need to develop the application and the provider takes care of managing servers. This concept is also known as Function-as-a-Service (FaaS). Developers write code for their business in the form of functions and deploy it. The provider takes care of provisioning, maintaining, and scaling the infrastructure as the application needs. 

Now that we know what serverless applications are, let’s try and understand why we need to secure serverless applications. 

Why do we need to Secure Serverless Applications?

To understand why we need to secure serverless applications, let’s first try to understand how these applications are different from other applications. 

In traditional applications, in addition to the security within the application itself, you could improve security by using firewalls, IDS/IPS, RASP (run-time application self-protection), etc. These tools and frameworks make use of the infrastructure the application runs on. But this is not the same with serverless applications. When you choose a serverless infrastructure, most cloud providers take care of security for the operating system, networks, and platform vulnerabilities from their side. However, since you don’t have access to the servers, the use of firewalls, IDS/IPS, and similar tools is not possible. 

This is why we need to secure serverless applications. Although the provider takes care of basic security, it’s up to us to add additional security to the applications. Serverless applications are secured using behavioral protection, code protection, permissions, secure API practices, and other approaches that don’t rely on the underlying infrastructure. 

But if the provider is taking care of basic security, why do you still need to secure serverless applications? To understand why basic security is not enough, let’s go through some risks of insecure serverless applications.

Risks of Insecure Serverless Applications

Increased Attack Surfaces

Serverless applications receive data input from a variety of sources. To name some - APIs, cloud storage, and data streams. Additionally, we might also have data flowing between different functions. One of the first rules of security is never to trust input and always take preventive measures. 

We can’t always be sure that these inputs are secure. Due to this, the attack surface of the application increases. In other architectures, firewalls, IDS/IPS could handle most of such cases and prevent them from reaching the application. But as we don’t have them in serverless applications, the application takes all the hit. 

Security Misconfiguration

Serverless architecture is not as mature as its alternate architectures. Due to this, you can still get into uncharted waters. Not to mention, this also increases the probability of getting things wrong. 

Service providers provide multiple features and configuration options to set up secure serverless applications. It’s crucial to know the impacts and consequences of configuring these and configuring the application as an insecure configuration might lead to attacks. 

One of the most common examples of serverless application misconfiguration is a long timeout and concurrency limit. Setting the timeout to the maximum allowed is a common practice as you don’t need to frequently tune it and it also doesn’t add additional overhead. Such misconfigurations can be leveraged to perform Denial-of-Service attacks. Therefore security misconfigurations can lead to attacks and/or breaches. 

Dependencies and Third-party Libraries

Developers do not like to reinvent the wheel. They’d rather use an existing dependency or third party library to get the task done than build it from scratch. This is really helpful to build applications faster. However, this creates a potential risk. If these libraries or dependencies have vulnerabilities or security issues, they can induce them into the application. 

One such example of a dependency causing a major security threat is the Log4Shell vulnerability in the Apache Log4j utility. This vulnerability could let an attacker execute arbitrary commands. 

Access and Permissions

A serverless application is comprised of multiple functions. These functions might need to interact with different components of the application and also communicate with each other. For example, you can have a function to alert an analyst on duty when suspicious activity is found. And you can have another function to get the details of the analyst on duty to alert them. To be able to do so, they need some privileges. Although access and permissions are needed to get the application working as expected, it also creates a potential risk. 

If the privileges assigned to the functions are more than what they need, attackers can leverage them to perform unsafe actions. And this also creates the risk of accidental actions of functions due to a malfunction. 

These are some of the most common security risks to insecure serverless applications. The question that arises now is “Are serverless applications worth the risk?” In order to enjoy the benefits of serverless architecture, there are some security practices you can follow to reduce the risks. 

Best Serverless Security Practices

Secure Configurations and Data Handling

When building serverless applications, it’s important to know what sensitive data is and how it’s accessed. Sensitive data such as passwords and secret keys should be encrypted and not kept as plain text. You should secure data-in-transit and data-at-rest to ensure high security. 

You should set function timeouts to the minimum. This reduces the time attackers get to do damage if they execute a successful code injection. You should also be reduced to a minimum to prevent DoS attacks.

The Principle of Least Privileges

The principle of least privileges is a practice that one should follow not just for serverless applications but everywhere. As discussed previously, privileges that are not required pose a security threat. The principle of least privileges states that you should give an entity only the minimum level of privileges to perform its task. 

This practice prevents accidental malfunction and also prevents attackers from misusing additional privileges given to a function. 

Use API Gateways as Security Buffers

Serverless functions are usually accessible over HTTP endpoints. With data coming from different sources and in different formats, it becomes difficult to secure applications from insecure data. One of the approaches to handle this risk is to use API gateways as security buffers. 

API gateways act as reverse proxies that provide a separation layer between users on the client side and backend functions on the serverless architecture. This reduces the attack surface as unsafe data can be filtered out before it reaches the application function. 

Sufficient Serverless Monitoring and Logging

Last but not least, you should have a sufficient monitoring and logging system to get visibility into your serverless application. Monitoring and logging serverless applications help you understand how your application responds to malicious actions. It’s proof that your security practices are working as expected. Additionally, knowing the attack attempts on your application will also help you plan further security implementation for your application. 

Conclusion

Serverless applications might be the next revolution of cloud-native applications. Serverless architectures help developers focus on building the application rather than managing servers making their job easy. These new applications offer you multiple benefits. But along with that, they also bring some risks. 

We’ve covered some of the most common risks of insecure serverless applications and some best serverless security practices that would help you secure your applications. To secure serverless applications, the best practices are not the end goal, they’re the baseline, the place where you start. Securing these types of applications is a continuous process. Having said this, I’d like to wish you an attack and breach-free experience in your serverless application journey!