Main Challenges in Securing FaaS Services

The security implications of FaaS in terms of benefits and concerns is still an open topic that requires additional research. The serverless architecture in a general perspective, has mainly positive outcomes when it comes to security due to the fact that the underlying system is patched, updated and managed by the cloud provider. This fact effectively removes all system security responsibilities from the application developers and leaves only the application-level security to them. In the architecture of FaaS, the developer that needs to run the code does not need to know or care about the underlying operational issues of how many servers/containers are required, networking and storage issues associated with the operation of the code, or with maintenance, updating, patching, and securing the servers supporting the functionality—that is all the responsibility of the cloud provider. Besides this significant benefit, the serverless architecture, has some security concerns that mainly stem from its complex, stateless and segregated nature that will be presented through ought this post.

Common Security Issues

While it would appear that the usage of FaaS removes most of the security issues and responsibilities from the developers, this is only true in part; while the developer has delegated the applied security associated with the servers and the host OS to the cloud provider (and most of the times the security issues of central common applications such as databases), the organization is still fully responsible for the security of their deployed function-application, its communications and its identity and access management. 

This function-application security includes but is not limited to:

  • The actual code that runs in each function.
  • The connection and communication between function components in the context of the application.
  • The authentication and authorization of functional components, users and other internal or external entities. This falls into the scope of identity and access management, a service that is commonly provided by the cloud services.
  • The protection and validation of data and communications.
  • The analysis and protection from vulnerabilities in code, modules, and libraries that the application calls and uses —including third-party code or services.
  • The storage, management and deployment of application secrets in each FaaS component of the application.
  • The DevOps methodology as it is applied in FaaS. Given the rapid creation of new features and deprecation of old ones, additional procedures must be considered for the management of deprecated and new components. A component onboarding/offboarding procedure could be standardized for each application.

    Given the aforementioned facts, the OWASP organization has provided a top-10 list with the most common security vulnerabilities that provides an analysis of common attack vectors in the context of FaaS serverless applications. These attacks mainly focus on the application security given the fact that system security is off-loaded to the cloud provider. The list is the following:

  • Injection (major security concern)
  • Broken Authentication (moderate security concern)
  • Sensitive Data Exposure (Moderate Security Concern)
  • XML External Entities (Low Security Concern)
  • Broken Access Control (Moderate Security Concern)
  • Security Misconfiguration (Major Security Concern)
  • Cross-Site Scripting (Moderate Security Concern)
  • Insecure Deserialization (Major Security Concern)
  • Using Components with Known Vulnerabilities (Major Security Concern)
  • Insufficient logging and monitoring (Major Security Concern)

Despite these ten vulnerabilities, the list also identifies other types of vulnerabilities that are common amongst serverless architecture. These include (i) denial of service (minor), where resources are peaked to the set limit by the administrator, (ii) denial of wallet (moderate), where the resources are escalated to such a degree that the organization is not able to pay for the requested fee, (iii) insecure shared space (moderate), where remounted shared drives are not properly cleaned from previous runs of the container and (iv) Business logic / flow manipulation (major), that targets at exploiting the higher level logic implemented by the serverless components of the application.

Denial of Service and Sustainability

An additional concern when it comes to securing a FaaS applications, is the distributed denial of service (DDoS) attacks. More specifically, FaaS provides almost infinite scaling, something that deems most DDoS attacks irrelevant, but at a cost. Scaling applications to such degrees could cost to the developers large amounts of money that will ultimately make the application unsustainable (economic denial of sustainability – EDoS attack). Besides this, the developers could potentially add some kind of brakes that will stop the escalation of resources to reduce charges, but this in turn will enable once again the traditional DDoS attacks. The most common solutions to this matter are the approaches of network monitoring and when an attack pattern is identified, the associated IP addresses are blocked to thwart the attack. This is implemented either through cloud service provider services or in-house built intrusion prevention systems.

Security Enhancements

The majority of solutions trying to enhance security and privacy properties of FaaS architectures, use the Intel SGX as a trust anchor, a hardware-backed trusted execution environment, which can be utilized for running functions in private memory regions called enclaves. This solution allows for trustworthy execution of applications even in remote and unknown environments. Using such a solution in the context of FaaS will allow developers to be sure that their code is properly and securely executed, especially when handling sensitive and private data. In the context of privacy, the usage of blockchains has been proposed many times as a solution for privacy in the cloud and FaaS applications, especially when it comes to the protection of healthcare data.

Other Projects

The TRUSTEE project cluster is a consortium of projects that all have the common denominator of security and privacy in the cloud. TRUSTEE (data pRivacy and cloUd Security clustEr Europe) is an aggregation of results of 11 research projects funded by the European Union that was established within the Common Dissemination Booster initiative.


Although much of the security concerns are offloaded to the cloud service provider in a FaaS application, there are still important considerations left to the developers which are accompanied with new security issues to be tackled. The PHYSICS project will strive to ensure that the final solution will maintain the highest levels of security and privacy of the data handled. Based on the aforementioned security and privacy observations as they are applied to a FaaS environment, the project will build security by design and will strive to incorporate it in all major decisions.

Follow INQ on Twitter and on LinkedIn to see the latest updates!

You might be interested in …


View our previous Newsletters

Sign up to stay informed on our latest updates!