FaaS-Native Threats: Deconstructing the Unique Security Vulnerabilities of Serverless Architectures

Posted on by uplatzblog

Summary: 

Serverless computing, and its core compute model Function-as-a-Service (FaaS), represents a paradigm shift in application development, abstracting infrastructure management and enabling event-driven, auto-scaling architectures.1 FaaS platforms—such as AWS Lambda, Azure Functions, and Google Cloud Functions—allow developers to focus solely on writing application logic that runs in response to events, while the cloud service provider (CSP) handles all server provisioning, management, and scaling.3

This abstraction, however, does not eliminate security risk; it fundamentally transforms it. The traditional security model, focused on network perimeters and host-level hardening, becomes obsolete.5 Security responsibility shifts entirely to the domains of application code, data, and, most critically, identity and access management.6 This new model introduces a class of FaaS-native vulnerabilities that are more abstract, harder to detect, and intrinsically linked to the event-driven, ephemeral nature of the platform.

This report provides a technical analysis of the unique security challenges in FaaS architectures. It deconstructs the event-driven attack surface, examines vulnerabilities arising from the “cold start” mechanism and state management, and details the systemic architectural flaws that define the serverless threat landscape.

bundle-combo-sql-programming-with-microsoft-sql-server-and-mysql By Uplatz

The New Perimeter: Redefining Shared Responsibility in FaaS

Understanding FaaS security begins with the shared responsibility model, which is radically different from that of traditional Infrastructure-as-a-Service (IaaS).8

The FaaS Responsibility Model

In any cloud model, the CSP is responsible for “security of the cloud,” protecting the global hardware, network, and facilities that run all services.9 The customer is responsible for “security in the cloud,” managing their data, configurations, and access controls.7

In a FaaS model, the CSP’s responsibility is significantly expanded. The provider manages:

  • The Host Operating System: The CSP is responsible for all OS-level patching and hardening.10
  • The Application Runtime: The provider curates and patches the language runtimes (e.g., Python, Node.js) and base container images.12
  • The Execution Environment: The provider manages the underlying platform, virtualization, and isolation between function instances.6

The customer’s responsibility narrows but intensifies. With infrastructure concerns abstracted away, the customer is left with a small but critical set of responsibilities:

  • Application Code Security: Securing the function logic itself against vulnerabilities.
  • Data Security: Classifying and encrypting data.
  • Identity and Access Management (IAM): Configuring the permissions for each function, which is the most critical security control in FaaS.

 

Contrast with IaaS

 

This model stands in stark contrast to IaaS (e.g., Amazon EC2, Azure VMs). In an IaaS model, the customer retains a large portion of the security burden, including managing the guest operating system, all application-level software, security patches, and network configurations like firewalls and virtual networks.8 In FaaS, these responsibilities are entirely offloaded to the CSP.12

The critical implication of this shift is that the security perimeter is no longer a network firewall or a hardened host. In FaaS, the perimeter becomes an abstract, logical construct: the IAM role attached to the function and the validation logic within the function’s code. Attackers no longer scan for open ports; they scan for over-privileged roles and unvalidated event triggers.

 

The Event-Driven Attack Surface: A New Breed of Injection

 

The primary attack surface in FaaS is defined by its event-driven nature.13 The Open Web Application Security Project (OWASP) Top 10, the global standard for web application risks, has been re-interpreted for serverless, highlighting that traditional vulnerabilities like injection attacks manifest in new and more dangerous ways.16

 

S1: Event Injection—Bypassing the Traditional Perimeter

 

In the standard OWASP Top 10, Injection (A03:2021) is a well-understood risk, typically involving an attacker sending malicious data via an HTTP request (e.g., SQL injection in a form field).18 In serverless, this vulnerability is categorized as Event Injection and its scope is far wider.21

FaaS functions are triggered by a wide array of event sources beyond HTTP-based API Gateways, including cloud storage (S3), message queues (SQS, SNS), database streams (DynamoDB), and IoT events.5 Traditional security controls, such as Web Application Firewalls (WAFs), are designed to inspect HTTP traffic and are blind to these non-HTTP event sources.23

This architectural design creates a massive, undefended “side-door” attack surface. An organization may have a WAF securing its “front door” (the API Gateway), giving a false sense of security. An attacker can completely bypass this WAF by crafting a malicious payload and delivering it through a “trusted” internal event source, such as an S3 file upload or an SQS message.23 In this scenario, the function’s own input validation logic is the only line of defense.

 

Deep Dive: Non-HTTP Event Injection Vectors

 

Attackers exploit the implicit trust developers place in internal cloud services.23 Malicious, user-controlled data is “laundered” through these services to trigger an injection attack. Common vectors include:

  • Storage Triggers (e.g., AWS S3): A function is configured to process files upon upload. An attacker uploads a file with a malicious name, such as ‘;(os.system(‘rm -rf /tmp/*’));’.jpg.25 The s3:ObjectCreated event trigger passes the event JSON—containing the malicious filename—to the function. If the function’s code uses this filename string to build an OS command without sanitization, the command is executed.27
  • Messaging Triggers (e.g., AWS SQS/SNS): An attacker may find a public-facing function that publishes messages to an SQS queue. They can send a malicious JSON payload to this queue. A separate, internal-facing function (e.g., a payment processor) consumes from this queue. This downstream function, assuming the data is “internally generated” and therefore safe, deserializes or processes the malicious payload, leading to an attack.28
  • Database Triggers (e.g., DynamoDB Streams): An attacker with permission to update their own user profile in a database (a seemingly low-risk action) injects a payload into a field. The DynamoDB Stream, which captures this data change, triggers a downstream function that processes the “new” (malicious) data, executing the payload.28
  • Insecure Deserialization: Many event payloads are complex JSON or XML objects. If a function blindly deserializes this event data into a code object, it can be vulnerable to insecure deserialization attacks, leading to remote code execution.29

 

Exploiting Decoupled Business Logic (SAS-09)

 

In monolithic applications, business logic is a single, sequential process. In FaaS, business logic is a distributed system, an emergent property of multiple, decoupled functions chained together by events.30 This decoupling creates a vulnerability known as “Serverless Business Logic Manipulation”.31

An attacker can subvert the expected sequence of operations. For example, a “checkout” application may be a chain: ValidateCart $\rightarrow$ ProcessPayment $\rightarrow$ CreateOrder, with each function triggering the next. An attacker who discovers the event trigger for the CreateOrder function (e.g., a specific SQS queue) may be able to publish a message directly to that queue, executing the CreateOrder function and completely bypassing the validation and payment steps.

A common misconfiguration enabling this is an “unlocked” API Gateway, where an endpoint is missing an “authorizer”.32 This allows an attacker to invoke internal functions directly, leading to data leaks and business logic exploitation.32

 

Case Study: The ‘ServerlessGoat’ Compounding Vulnerability

 

The OWASP ServerlessGoat project is an intentionally vulnerable FaaS application that demonstrates these risks.33 A key vulnerability (SAS-01: Event Injection) allows an attacker to pass OS commands through a document_url parameter.26

This injection attack, while problematic, becomes catastrophic due to a second vulnerability: SAS-04: Over-privileged Function Permissions.33 The function is configured with a FullAccess policy for S3 and DynamoDB.

This demonstrates the compounding nature of FaaS vulnerabilities:

  1. The Vector (SAS-01): The event injection provides the attacker with initial code execution.
  2. The Blast Radius (SAS-04): The over-privileged IAM role gives that execution context god-like permissions.

A successful injection into a least-privilege function would be contained. A successful injection into the ServerlessGoat function allows the attacker to pivot, exfiltrate all data from the application’s database and storage, and achieve a full-system compromise from a single flaw.

 

Exploiting the Ephemeral: Cold Start Vulnerabilities and State-Based Risks

 

The second major class of FaaS-native vulnerabilities arises from the platform’s core operational mechanics, particularly the “cold start.”

 

Cold Starts: From Performance Anomaly to Security Vector

 

A “cold start” refers to the latency incurred when a new request triggers the FaaS platform to initialize a new execution environment (e.g., a container).36 This involves downloading the code, starting the container, and initializing the runtime.38 A “warm start,” by contrast, reuses an existing, already-initialized container, which is much faster.39

Operations teams view cold starts as a performance problem to be minimized.38 However, the state difference between a “cold” and “warm” instance, and the platform’s mechanism for reusing warm containers, creates a non-obvious and potent attack surface.21 The platform’s attempt to optimize performance directly creates a security vulnerability: accidental state persistence.

 

Data Leakage from Quasi-Persistent State

 

FaaS functions are designed to be stateless.39 This is a design principle, not a platform guarantee.44

In reality, the FaaS execution context—specifically the /tmp directory and any global variables in the code—persists between “warm” invocations for the same container.21 This creates a “quasi-persistent” state.44

This leads to a cross-invocation data leakage vulnerability:

  1. An invocation for User A triggers a function.
  2. The function code writes sensitive data (e.g., PII, session tokens, decrypted files) to /tmp as part of its logic.
  3. The function completes but fails to scrub the /tmp directory.
  4. A new invocation for User B arrives moments later.
  5. The platform, optimizing for performance, routes this new request to the same warm container used for User A.
  6. The function code for User B can now read the “stale” sensitive data left in /tmp by User A, breaking tenant isolation.

 

Side-Channel Attacks via Resource Contention

 

The FaaS abstraction hides, but does not eliminate, the underlying shared physical infrastructure.39 Academic research has demonstrated that this abstraction is “leaky” and vulnerable to classic side-channel attacks.

Researchers have identified “exploitable placement vulnerabilities” on platforms like Azure, allowing a malicious tenant to intentionally co-locate their function on the same physical VM as a victim’s function.43 Once co-resident, the attacker can launch sophisticated side-channel attacks, such as cache-timing 46 or monitoring resource contention 39 and filesystem artifacts, to infer data or activity from the victim function (e.g., cryptographic key operations). This proves that FaaS is still susceptible to “noisy neighbor” attacks, a deep-level hardware vulnerability that the developer has no visibility into or control over.39

 

Economic Denial of Service: The Denial of Wallet (DoW) Attack

 

Perhaps the most unique FaaS-native vulnerability is the Denial of Wallet (DoW) attack, an economic attack vector that targets the pay-per-execution billing model.13

A traditional Denial of Service (DoS) attack aims to exhaust resources (CPU, bandwidth) to make a service unavailable.39 A DoW attack, by contrast, aims to exhaust finances. The attacker leverages the platform’s infinite auto-scaling feature 4 against the victim. The attack is simple: invoke a target function millions of times.50

The service remains perfectly available; the FaaS platform dutifully scales to meet the malicious demand. The victim’s users experience no outage. The attack is only discovered when the victim receives an astronomical cloud bill at the end of the month.48

A critical finding in DoW research is the persistent lack of public, real-world data on these attacks.52 This lack of data is itself an indicator of the threat’s nature. A traditional DoS is publicly visible (the website is down). A DoW attack is a private financial transaction between the victim and their CSP. There is no data breach to disclose and a strong financial and reputational incentive not to disclose the attack, making DoW a silent and insidious economic weapon.

 

Advanced DoS Case Study: The ‘Warmonger Attack’

 

The “Warmonger attack” is a novel DoS vector, documented in academic research, that is uniquely enabled by the FaaS multi-tenant architecture.49 This “bank-shot” attack weaponizes the platform’s own infrastructure to create collateral damage.

The exploitation mechanism proceeds as follows 55:

  1. Shared Egress IPs: FaaS platforms use a small, shared pool of egress IP addresses for all functions (even those belonging to different tenants) to access the public internet.49
  2. Attacker Action: An attacker, as a paying tenant on the FaaS platform, deploys a function to send “misbehaving” traffic (e.g., an HTTP flood) to an external, third-party Target Server.
  3. IPS “Infliction”: The Target Server’s Intrusion Prevention System (IPS) detects this attack and, as a standard defensive measure, blocks the malicious source IP address.55
  4. Collateral Damage: The blocked IP is one of the FaaS platform’s shared egress IPs.
  5. Platform-Wide DoS: All other innocent functions on the same platform, belonging to different tenants, are now unable to access the Target Server, as their legitimate traffic is blocked by the Target’s IPS.

The Warmonger attack is the inverse of a traditional DoS: the attacker is not trying to avoid the IPS; they are trying to deliberately trigger it to poison the platform’s reputation and create a platform-wide, self-inflicted DoS.49 Research has also linked this attack to “cold-start churn” as a method to degrade performance and increase costs.58

 

Table 1: Cold Start and State-Based Attack Vector Analysis
Vulnerability Platform Mechanism Exploited Attacker’s Goal Primary Defense
Quasi-Persistent State Leakage Container reuse (Warm Starts); Persistent /tmp directory 21 Read sensitive data from a previous, separate function invocation 44 Secure coding (scrub /tmp); Runtime monitoring
Side-Channel Attack Co-resident VM placement; Shared physical hardware 39 Infer data (e.g., crypto keys) from a co-located victim function 46 Provider-level isolation (no customer defense)
Denial of Wallet (DoW) Pay-per-execution billing; Auto-scaling 48 Generate a massive cloud bill for the victim without causing an outage [13, 54] Rate limiting; Billing alerts; Throttling 32
Warmonger Attack Shared egress IP pool for all tenants [55, 56] Trick a 3rd-party IPS into blocking the FaaS platform’s shared IP, causing collateral DoS [49] Customer: VPC/NAT Gateway. Provider: IP rotation.

 

Systemic Architectural Vulnerabilities in FaaS

 

Beyond event-specific and state-based attacks, the FaaS model suffers from systemic vulnerabilities rooted in its developer-centric, highly distributed nature.

 

Over-Privileged Function Permissions (SAS-04)

 

As established, the IAM role is the new perimeter. SAS-04 (Over-Privileged Function Permissions & Roles) is arguably the single most critical and common FaaS vulnerability.13

This vulnerability is endemic because it stems from developer convenience. Crafting a perfect, fine-grained, least-privilege IAM policy for every single function is complex and time-consuming.59 Under project deadlines, developers often resort to using broad AWS-managed policies or, worse, wildcard policies (“Action”: “*”, “Resource”: “*”) to “make it work,” with the intention of refining them later.21

This practice turns the IAM role into a “blast radius multiplier.” It is the vulnerability that compounds all others. An injection attack (SAS-01) against a function with a least-privilege policy is contained. The same injection against an over-privileged function, as seen in ServerlessGoat, becomes a full-system compromise.35

 

Insecure Third-Party Dependencies (SAS-06)

 

The FaaS model, which encourages small, single-purpose functions, also encourages a heavy reliance on third-party packages and open-source libraries to provide functionality quickly.13 This dramatically increases the attack surface for supply chain vulnerabilities.50

Attackers use techniques like typosquatting (publishing malicious packages with names similar to popular ones) 61 or hijacking legitimate, popular packages to inject malicious code.62

This creates another potent “compounding vulnerability”:

  1. The Vector (SAS-06): A developer imports a malicious or compromised npm package.61
  2. The Payload (SAS-07): The developer “insecurely” stores application secrets (API keys, database passwords) in plaintext Lambda environment variables.21
  3. The Exploit: When the function is invoked, the malicious package’s code executes. It does not need to perform discovery or pivot. It simply reads the process.env variables, steals the plaintext credentials, and exfiltrates them to the attacker’s server.69 The entire attack is over in milliseconds.

 

The Observability Challenge: Monitoring Ephemeral “Crime Scenes”

 

The ephemeral and distributed nature of FaaS creates a profound “visibility gap” for security teams.42

Traditional, agent-based security monitoring tools are rendered useless in FaaS.7 An agent, which relies on a long-lived server, cannot even initialize before a FaaS function has already executed and terminated (often in milliseconds).73 This ephemerality provides intrinsic anti-forensic properties for an attacker. The “crime scene”—the execution container with its memory and temporary files—is automatically destroyed by the platform immediately after the attack.69

Security teams face two core challenges 42:

  1. Data Collection: Difficulty in reliably collecting logs and metrics from resources that constantly appear and disappear.71
  2. Data Correlation: Difficulty in correlating sparse logs from thousands of distributed, stateless functions to reconstruct a single, multi-step attack path.24

Relying solely on native CSP logging tools is often insufficient, as they lack the application-layer context to distinguish between benign and malicious behavior.5 This “visibility gap” means that an attacker can execute a supply chain attack, steal credentials, and exfiltrate data, and the entire event—including all evidence—is gone before an alert can even be triaged.

 

A Proactive Defense Posture for Serverless Architectures

 

Securing FaaS requires a multi-layered, FaaS-native strategy that addresses these unique risks at the level of identity, code, and runtime.

 

Foundational Defense: Implementing True Least Privilege

 

The single most effective defense is the strict enforcement of the Principle of Least Privilege.74 This cannot be an aspiration; it must be a mandate.

  • Role-per-Function: Abandon shared, broad IAM roles. Every individual function must have its own unique IAM role granting only the minimal set of permissions required for its specific task.21
  • Fine-Grained Policies: Policies must be specific. A “bad” policy is “Action”: “*”. A “good” policy is “Action”: “dynamodb:GetItem”, “Resource”: “arn:aws:dynamodb:us-east-1:123456789012:table/Orders”.21
  • Automation: Manually managing thousands of roles is unscalable. Teams must leverage automated tools like AWS IAM Access Analyzer to generate fine-grained policies based on observed access activity.74

 

Securing the Event-Driven Pipeline: Zero-Trust Validation

 

A Zero-Trust security posture must be adopted at the code level.78 All event payloads must be treated as untrusted input, regardless of their source.21 The fact that an event originated from an “internal” S3 bucket or SQS queue is irrelevant.

  • Syntactic and Semantic Validation: All input data must be validated against a strict schema. This includes enforcing data types, formats, and lengths (syntactic validation) as well as business logic rules (semantic validation).80
  • Allow-List Validation: Use allow-lists (defining what is permitted, e.g., ^[a-zA-Z0-9_.-]+$) rather than deny-lists (banning “bad” characters like <script>), which are brittle and easily bypassed.81
  • Sanitization and Encoding: Input should be sanitized to remove harmful characters, and all output must be contextually encoded to prevent injection attacks like XSS.80

 

Secrets Management: Isolating Credentials from Code

 

The cardinal sin of FaaS security is storing secrets in plaintext environment variables.21 This practice is a direct invitation to the supply chain attacks previously described.

The correct architecture involves using dedicated, managed secrets services like AWS Secrets Manager 84, Azure Key Vault 85, or HashiCorp Vault.88

The most modern retrieval practice, for example in AWS, is to use the AWS Parameters and Secrets Lambda Extension.89 This extension solves both the security and performance problems of secrets management:

  1. Security: The secret is never stored in the function’s environment variables. It is fetched by the extension and cached locally.89
  2. Performance: The function retrieves the secret from a local HTTP endpoint. The extension handles the caching and refreshing, which avoids the API call latency to Secrets Manager and mitigates the impact on function cold starts.82

 

Runtime Security: Addressing the Ephemeral Monitoring Gap

 

The “visibility gap” (Section 4.3) and runtime-specific threats (Sections 2 and 3) prove that static code scanning and native CSP logs are insufficient. A modern FaaS security posture requires runtime protection.5

This need is filled by a new class of security tooling, primarily Cloud Workload Protection Platforms (CWPP) and Cloud-Native Application Protection Platforms (CNAPP).

Table 2: FaaS Security Tooling Comparison: CNAPP vs. CWPP
Capability Cloud Workload Protection Platform (CWPP) Cloud-Native Application Protection Platform (CNAPP)
Primary Focus “Shield-Right”: Runtime protection of active workloads. Holistic (End-to-End): Lifecycle security from code to cloud.[90]
Scope Workload-centric: VMs, containers, and serverless functions.[91, 92] Consolidates multiple tools: CWPP + CSPM + CIEM + IaC Scanning.[92, 93]
Serverless Runtime Protection Yes. Core feature. Detects anomalous behavior, injection attempts, and data exfiltration at runtime.[91] Yes. Includes CWPP capabilities for runtime protection.[90]
Posture Management (CSPM) No. Yes. Scans cloud configurations to find misconfigurations (e.g., public S3 buckets).[90]
Identity (CIEM) Analysis No. Yes. Analyzes IAM roles to detect over-privileged functions (SAS-04).[92]
IaC / Shift-Left Scanning Limited. Yes. Scans deployment templates (e.g., Terraform, CloudFormation) to find flaws before deployment.[92]

A CWPP is essential for “shield-right” runtime defense, providing the real-time visibility needed to detect an attack within an ephemeral function.91 A CNAPP provides a more comprehensive, strategic solution. It bundles CWPP for runtime protection and integrates “shift-left” capabilities (like CSPM and IaC scanning) to find and fix the very misconfigurations (like over-privileged roles and unlocked event triggers) that enable breaches in the first place.90

 

Conclusion: The New Security Contract of FaaS

 

The adoption of Function-as-a-Service does not eliminate security risk; it transforms it. The abstraction of the server 7 shifts the entire defensive burden from tangible, static perimeters (networks, hosts) to abstract, dynamic, and logical constructs: IAM policies, event schemas, and application code.

The unique event-driven 14 and ephemeral 42 nature of FaaS creates an entirely new class of FaaS-native attack vectors that render traditional security tools and mental models obsolete. These include:

  1. Event Injection: Bypasses traditional WAFs by “laundering” malicious payloads through “trusted” internal cloud services like S3 and SQS.28
  2. Cold Start Vulnerabilities: Weaponizes the platform’s own performance optimizations to enable cross-invocation data leakage 21, sophisticated side-channel attacks 43, and novel economic DoS attacks like “Denial of Wallet” 48 and “Warmonger”.55

These vectors are dangerously compounded by systemic flaws. Over-Privileged Functions (SAS-04) 59 and Insecure Secrets Storage (SAS-07) 70 act as blast-radius multipliers, turning minor injection 35 or supply chain flaws into catastrophic, full-system breaches.

Ultimately, securing FaaS requires a new security contract. This contract must be built on a “Zero-Trust” posture 78 that treats all events as untrusted, enforces a non-negotiable “role-per-function” least-privilege identity model 21, and implements a modern CNAPP/CWPP strategy.90 Only this holistic approach can provide the necessary end-to-end visibility, from pre-deployment “shift-left” configuration analysis to “shield-right” protection of the ephemeral runtime itself.