Serverless architecture, and in particular the Functions-as-a-Service (FaaS) model, is one of the most revolutionary changes in the paradigm of cloud application development and deployment. The promise is extremely enticing: developers can focus solely on writing the code that implements the business logic, and all responsibility for managing servers, scaling, patching and maintaining the infrastructure is delegated to a cloud provider, such as AWS (with its Lambda service) or Microsoft (with Azure Functions). An application no longer runs as a monolithic, continuously running process, but as a collection of small, independent functions that run “on demand” and exist for only a few hundred milliseconds, and are paid only for the actual time they take to execute.
But this revolution in architecture entails an equally revolutionary change in the approach to security. In a serverless world, traditional reference points are disappearing. There is no longer an operating system to “harden,” an application server to configure or an EDR agent to install. The attack surface is completely changing, and the focus of security teams must shift from protecting the infrastructure to protecting the code itself, its permissions and the events that trigger it. It’s a new, ephemeral world that requires a new set of rules and defense tools.
Shortcuts
- What is serverless architecture and the Functions-as-a-Service (FaaS) model?
- How is the security responsibility model changing in serverless architecture?
- What are event injection attacks and why are they the biggest threat to serverless functionality?
- Why is excessive authority (IAM) assigned to a function such a critical risk?
- What is the OWASP Serverless Top 10 and how does it help identify key risks?
- How can nFlo help audit and secure serverless applications?
What is serverless architecture and the Functions-as-a-Service (FaaS) model?
Serverless architecture is a model for developing and running applications in which the cloud provider is fully responsible for managing the server infrastructure. The name “serverless” is somewhat misleading - servers still exist, of course, but they are completely abstract from the developer’s perspective. He doesn’t have to provision, configure, patch or scale them.
FaaS (Functions-as-a-Service) is the most popular incarnation of serverless architecture. In this model, an application is decomposed into small, stateless functions, each of which is responsible for performing one specific operation (e.g., processing an image, handling an API query, writing to a database). Each such function is uploaded to a FaaS platform (e.g. AWS Lambda, Azure Functions, Google Cloud Functions), where it remains dormant.
A function is “woken up” and triggered only when a specific event (event), called a trigger, occurs. The trigger can be an HTTP request to the Gateway API, the upload of a new file to the S3 tray, a new message in the SQS queue or a change in the DynamoDB database. After completing its task, the function “goes to sleep” again. This event-driven model allows for tremendous scalability and cost efficiency.
📚 Read the complete guide: Cloud Security / AWS: Public cloud security - AWS, Azure, best practices
How is the security responsibility model changing in serverless architecture?
The shift to a serverless model involves a fundamental change in the shared responsibility model between the customer and the cloud provider. In the traditional IaaS (Infrastructure-as-a-Service) model, where we rent virtual servers, the provider is responsible for the security of the “cloud” (i.e., the physical infrastructure) and the customer is responsible for the security of the*“in the* cloud” (operating system, network, applications).
In the FaaS/serverless model, the cloud provider’s responsibility is much broader. In addition to physical security, it assumes full responsibility for securing, patching and hardening the entire runtime environment - from the hypervisor to the operating system to the execution environment for a particular programming language (e.g. Python, Node.js). This is a huge relief for operations teams.
However, the customer’s responsibility does not disappear at all - it moves “higher” in the stack. In the serverless model, the customer is fully responsible for:
-
Security of the function code itself: Protection against vulnerabilities in the code being written and the libraries being used.
-
Entitlement Management (IAM): Giving each function the least amount of necessary permissions to operate.
-
Secure configuration of triggers and services: Securing, for example, Gateway APIs or S3 trays that initiate function execution.
-
Protection of data processed and stored by the function.
What are event injection attacks and why are they the biggest threat to serverless functionality?
In traditional web applications, one of the biggest threats has been SQL Injection or Command Injection attacks, where malicious code is injected into a query and executed by the server. In the serverless world, the equivalent and number one threat is event injection attacks.
Serverless functions are inherently driven by events. An event can be an HTTP request, the contents of a JSON file, a message from a queue or a record from a database. An event injection attack occurs when an attacker is able to craft the contents of such an event in such a way as to force the function to perform operations unintended by the developer.
Imagine a simple Lambda function that, after uploading an image to S3, reads its name from an event object and uses it to execute a command in the system shell (e.g., to resize it using ImageMagick). If the developer fails to properly validate and sanitize the file name, the attacker can upload a file named mojobrazek.jpg; rm -rf / in an attempt to inject an additional malicious command. Since each function has access to a temporary file system, such an attack, combined with excessive permissions, can lead to serious consequences. Protection against event injection requires rigorous validation of all event input.
Why is excessive authority (IAM) assigned to a function such a critical risk?
In a serverless architecture, identity and access management (IAM) becomes the absolutely central and most important security control mechanism. Every single function (e.g., AWS Lambda) executes in the context of the IAM role assigned to it, which defines what other cloud services and resources it has access to.
One of the most common and dangerous mistakes is to create a single, broad IAM role (a “fat function role”) and assign it to many different functions. Such a role often contains permissions that most functions don’t need at all, such as full access to all S3 trays in an account or write permissions to every DynamoDB table.
This poses a huge risk. If an attacker manages to find a vulnerability (e.g., of the event injection type) in one function, even the simplest one, that has such a broad role assigned to it, he automatically inherits all its excessive privileges. He or she can then use that compromised function as a “proxy” to launch an attack on other critical resources in the cloud - stealing data from S3, deleting records from the database or even creating new malicious resources. The key to serverless security is to rigorously apply the principle of least privilege and create a dedicated, minimalist IAM role for each individual function separately.
Biggest Threats to Serverless Applications (according to OWASP)
| Threat Category | Risk Description | Key Protective Action |
|---|---|---|
| Event Injection | Injection of malicious data into a function trigger event, leading to the execution of unintended operations. | Rigorous validation and sanitization of all input data from events. Avoid passing raw data to the command interpreter. |
| Incorrect Entitlement Configuration (IAM) | Assigning excessive, overly broad powers to functions, which, if compromised, allow the attack to escalate. | Apply the principle of least privilege. Creating a dedicated, granular IAM role for each individual function. |
| Vulnerable Dependencies (Libraries) | Code’s use of open-source library functions and dependencies that contain known vulnerabilities (CVEs). | Regular dependency scanning with SCA (Software Composition Analysis) tools and integration of this process into the CI/CD pipeline. |
| Inadequate Logging and Monitoring | Lack of detailed logs of function execution, which prevents attack detection and post-breach analysis. | Enable and centralize logging for each function. Monitor key metrics (errors, execution time) and create alerts for anomalies. |
What is the OWASP Serverless Top 10 and how does it help identify key risks?
OWASP (Open Web Application Security Project) is a global nonprofit organization that creates and publishes free, open standards and best practices for application security. In addition to the famous OWASP Top 10 list for web applications, the organization has also created a dedicated OWASP Serverless Top 10 list.
It is a document that identifies and ranks the ten most serious and common security risks in applications based on serverless architecture. It provides an invaluable guide for developers, architects and security professionals, allowing them to focus their efforts on the most important areas.
In addition to the aforementioned injection attacks (S-T1) and authentication errors (S-T2, which largely affects IAM), the list highlights other key risks, such as sensitive data leakage (S-T3 ), insufficient logging and monitoring (S-T10), vulnerabilities in third-party components (S-T6) or misconfiguration (S-T4 ). Using the OWASP Serverless Top 10 as a checklist when designing, developing and auditing serverless applications is one of the best practices in the industry.
How can nFlo help audit and secure serverless applications?
At nFlo, we have deep knowledge and hands-on experience in securing modern cloud architectures, including applications based on the serverless model. We understand the unique challenges of this paradigm and know where to look for hidden risks that often escape traditional security approaches.
Our key service in this area is a specialized security audit of serverless applications. As part of the audit, our team of experts performs a comprehensive analysis, covering all key aspects:
-
Review function source code for vulnerabilities, especially of the event injection type.
-
Analyze the configuration of IAM roles and policies to identify and eliminate excessive privileges.
-
Overview of the configuration of triggers (e.g., API Gateway) and related services.
-
Scan dependencies for vulnerable libraries.
Based on the audit, we provide a detailed report with specific, implementable recommendations. What’s more, we proactively support development teams in implementing these recommendations, helping to build secure patterns and integrate automated security checks (e.g., SCA scanners) directly into the CI/CD pipeline, following DevSecOps best practices. Our goal is to ensure that your organization can reap all the benefits of serverless innovation without exposing itself to new and unknown risks.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- Amazon Web Services (AWS) — Amazon Web Services (AWS) is a comprehensive and widely adopted cloud platform…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- NIST Cybersecurity Framework — NIST Cybersecurity Framework (NIST CSF) is a set of standards and best…
- Server — A server is a specialized computer or software that provides services,…
Learn More
Explore related articles in our knowledge base:
- Cloud Infrastructure Penetration Testing for AWS, Azure, GCP
- Multi-cloud security: How to manage risk in a multi-cloud environment?
- AWS security audit by CIS Benchmarks: From manual verification to intelligent automation - the road to cyber resilience
- Why is CIS Benchmarks compliance so critical for your AWS cloud security?
- Optimizing security costs in AWS: How to invest wisely in cloud security without overpaying?
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
