Serverless Application is not as secure as you might think!

What is a Serverless Application?

For running a traditional web application, you need to set up an OS, configure a web server, install a CMS and prepare a database. You should take care of infrastructure, capacity, and maintenance of servers as long as your application is running.

What if you could only focus on developing your application and don't think about the infrastructure? This is exactly what you can do in a Serverless architecture. You write your code and publish it on cloud servers like AWS Lambda, Cloudflare workers, or Google Cloud Functions. Your code will run on cloud servers, and your cloud provider manages and handles the infrastructure and maintenance.

Cloud companies that provide Serverless services offer different form of it. Take FaaS as an example. In this development model, cloud providers allow you to write your application in small separate functions. That's why this service is called Function as a service (FaaS). This approach supports trending architectures like the JAMstack (JavaScript, API & Markup). The JAMStack consists of static pages (the Markup) that integrate with the backend through the use of APIs in Serverless applications.

💡 PaaS is also another Serverless cloud service where you control the entire application. This is in contrast with FaaS that has an event-driven architecture. In FaaS, your application (function) gets executed in certain events like incoming requests.

Serverless Security

The Serverless development model has many benefits like cost efficiency, elasticity, and productivity. But Serverless applications are not more secure compared to traditional applications. Cloud providers like Amazon AWS take care of OS and platform vulnerabilities, but you don't have access to the servers, and you can't use classic security solutions like IDS/IPS that require installation on endpoints.

Further, in a Serverless architecture, the entire application consists of more small components, that means more entry points resulting in an increased attack surface.

Developing and running a Serverless application depends on the cloud provider's standards. This means the same code can not be used in another cloud provider without change.

Privacy is another concern in Serverless applications because of using shared resources and access by external employees in public Serverless cloud infrastructure.

Vulnerabilities in Serverless Applications

Security vulnerabilities affect different layers of any application like OS, web server, database, and the application itself. In Serverless architectures, the cloud provider takes care of all infrastructure security. So you won't worry about security misconfigurations and issues like Outdated server vulnerability. But the application security is still your responsibility in the Serverless development model. And unfortunately, many vulnerabilities relate to the application layer. Vulnerabilities like:

• SQL Injection
• Cross-Site Scripting (XSS)
• File Inclusion Vulnerabilities
• Cross-site Request Forgery (CSRF)
• Using eval and Command Execution
• Unvalidated Redirects and Forwards

These are generic vulnerabilities that are in OWASP's Top 10 list. We have covered some of them in articles like common web vulnerabilities and securing your NodeJs express application. In the followings, we will review vulnerabilities that are less known but more specific to Serverless applications.

Missing Function Level Access Control

Sensitive functionalities should be protected with an authentication mechanism. It doesn't matter whether these functionalities are served as web pages or an API. If anyone can access such functionalities, this is a broken access control flaw.

All administration use-cases are prone to this issue. You might have several Serverless APIs for tasks like managing accounts/posts or changing service status. You should make sure that only allowed users can access and use such functionalities.

Sensitive Data Exposure

Let's say you have a Serverless application for a voting system. One function of this platform is to show the vote counts for any candidate. Consider a Serverless function for displaying vote counts which accepts candidate ID and returns a list of every user who has voted for that candidate. So you can easily show the count of users as vote counts for the candidate.
But something's fishy here! We need a function to display vote counts, not to return name of voters! You might say that the list of users is not displayed anywhere, and only the count of users is represented. That's right, but as long as the Serverless function is returning all those information and it's publicly accessible, an attacker can abuse it.

Sensitive Data Exposure is a very common flaw. To avoid it you should return the minimum required data in your Serverless functions.

Insecure Direct Object Reference (IDOR)

Imagine an HR application that has a profile API that accepts an employee ID and returns the employee information. Let's say the employee IDs are an integer number and the Serverless function queries it on the database to find the employee. What could go wrong in this scenario? An attacker can build a collection of employee IDs by starting from 1 and incrementing to any number. Then this collection can be used to query your function to enumerate all employee information. This can happen if the API does not implement the proper access control we discussed earlier.

Here employee ID passed to the Serverless API is a reference to the employee record in the database. And this reference is directly controlled by the user. If such references are easy to guess, you risk your data being enumerated.

Avoid using guessable patterns for IDs (using hash can help). Make sure your functions have access control to mitigate IDOR flaws.

Template Language Injection

A common way of rendering HTML pages using a template is to evaluate an expression like 2+2 and display the results (4) in output. Template language injection or Expression language injection occurs when a user can change the expression used in the template.

Components with Known Vulnerabilities

Serverless applications are usually in JavaScript (or TypeScript) or Python languages. Developers in Python or JavaScript usually use numerous third-party packages for completing different tasks. These packages might have vulnerabilities, and using them can make your Serverless application vulnerable.

To mitigate component vulnerabilities, make sure you're using the updated version of any library and run security tests to find vulnerable packages.

💡 In NodeJs, you can use npm audit to find vulnerabilities in npm packages. Read Securing Your NodeJs JavaScript Project for details.

Conclusion

Serverless applications have many benefits and use cases like file transformation, providing dynamic contents, logging, and others. There's a misunderstanding that Serverless applications are more secure. This is true to some extent when it comes to OS vulnerabilities, but you need to take application layer security in your hand.

We reviewed some of the common vulnerabilities in Serverless applications, but you should know that these vulnerabilities are not complete and these are not even limited to Serverless applications. So security testing of your web applications is a crucial job for securing them.
Security of Serverless applications needs a DevSecOps solution where developers, operation team, and Security guys collaborate closely.