Serverless and Function Security

Serverless computing (Functions as a Service, FaaS) allows developers to deploy individual functions that are invoked by events — HTTP requests, queue messages, database triggers, or scheduled timers — without managing the underlying servers. Leading platforms include AWS Lambda, Google Cloud Functions, and Azure Functions. The cloud provider manages patching, scaling, and infrastructure. While this reduces operational burden, it shifts the security responsibility model: the provider secures the runtime, but the developer is solely responsible for function code, permissions, and configuration.

Serverless functions present a distinct attack surface compared to traditional applications: functions are typically short-lived (seconds to minutes), making traditional EDR and network monitoring less effective; they are event-driven, meaning many different input sources (S3 events, API Gateway, SNS) can trigger execution; they often run with IAM permissions that can access other cloud resources; and they consume third-party dependencies (npm, pip packages) that may contain malicious code. The attack surface is defined by event inputs, IAM permissions, and dependency trust chains.

The most common serverless security vulnerability is over-privileged IAM roles. When developers need a function to access one S3 bucket, it is tempting to assign s3:* (full S3 access) to avoid permission errors. A compromised or vulnerable function with this role can then read, write, or delete any bucket in the account. The defense is strict least-privilege IAM roles: each function should have a dedicated role granting only the minimum permissions required for that specific function's specific tasks. Tools like AWS IAM Access Analyzer and Cloudsplaining identify over-privileged Lambda roles automatically.

Event injection occurs when attacker-controlled data in an event payload is processed unsafely by the function code. Since serverless functions can be triggered by many event sources — HTTP headers, query parameters, database change records, queue message bodies, email content — any of these can carry malicious payloads. Common injection types include: SQL injection if the function queries a database using event data, NoSQL injection (MongoDB operators in JSON payloads), command injection if event data is used in OS commands, and SSRF (Server-Side Request Forgery) if URLs from event data are fetched. Input validation and parameterized queries are essential defenses.

Serverless functions frequently depend on dozens of third-party packages. These dependencies introduce supply chain risk: a malicious or compromised package can execute arbitrary code within the function's execution environment, access environment variables (which often contain secrets), make outbound network connections, and use the function's IAM role to access cloud resources. High-profile attacks like the event-stream npm package compromise (2018) and numerous typosquatting packages demonstrate this risk. Defenses include dependency pinning, SCA scanning in CI/CD, and minimal dependency footprints.

Serverless functions often receive secrets through environment variables configured in the cloud console. These environment variables are visible to anyone with IAM access to the Lambda configuration and can be accessed by any code running within the function. Best practices: avoid storing secrets directly as plaintext environment variables; instead, store ARNs or secret names and retrieve secrets at runtime from AWS Secrets Manager or Parameter Store; enable KMS encryption for Lambda environment variables at rest; and never log environment variables (many debug loggers dump all env vars on error).

Denial of service against serverless functions can take the form of invocation flooding — an attacker who can trigger a function repeatedly may exhaust the account's concurrency limit (Lambda's default is 1,000 concurrent executions per region), making other functions in the account unable to execute. Functions processing user-controlled input should implement rate limiting at the API Gateway level, validate payload size limits, and set appropriate timeout values to prevent runaway executions. Functions can also be targeted by Billion Laughs-style expansion attacks in XML/YAML parsing if input is not size-limited.

By default, AWS Lambda functions run in an AWS-managed VPC with internet access but no access to resources in your private VPC (RDS databases, ElastiCache, private APIs). To access private resources, Lambda must be configured to run inside your VPC with specific subnets and security groups. However, VPC-attached Lambda functions do not have internet access by default — they need a NAT Gateway for outbound internet. Security groups attached to Lambda functions should follow least-privilege rules: allow only the specific ports and destinations required. Avoid using 0.0.0.0/0 outbound rules on production function security groups.

Monitoring serverless security requires different approaches than traditional host monitoring. Since functions are ephemeral, host-based agents are impractical. Effective monitoring uses: AWS CloudTrail to log all Lambda API calls (invocations, configuration changes, role assumptions); CloudWatch Logs Insights to query function execution logs for anomalous patterns; Amazon GuardDuty for threat detection including unusual Lambda network activity; and commercial serverless-native security tools like Protego (now part of Check Point) or Datadog's serverless monitoring that instrument functions via layers to provide runtime visibility.

Testing serverless security requires specific tooling: PureSec CLI (now Check Point) and Prowler scan cloud configurations for serverless misconfigurations; DAST tools can test HTTP-triggered functions for injection vulnerabilities; static analysis of function code with tools like Bandit (Python) or ESLint security plugins catches insecure coding patterns; and manual testing should enumerate all event sources that can trigger each function and test each with malformed and malicious payloads. The OWASP Serverless Top 10 provides a comprehensive vulnerability checklist specific to serverless architectures.

Serverless computing extends the shared responsibility model further toward the provider. The cloud provider is responsible for: the function runtime environment, OS patches, underlying infrastructure security, and physical facilities. The customer remains responsible for: function code security, IAM permission design, secret management, input validation, dependency management, logging configuration, and network policies. The reduced infrastructure responsibility does not mean reduced security responsibility — it merely shifts where security investment should focus, primarily toward application-level and IAM security.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: over-privileged IAM roles are the primary serverless risk — each function needs a dedicated least-privilege role, event injection attacks exploit any event source that delivers attacker-controlled data to functions lacking input validation, and dependency supply chain risk from third-party packages can compromise function execution with access to IAM credentials and secrets. Next up we explore Infrastructure as Code security scanning to catch misconfigurations before deployment.