Insecure Serverless Functions

Insecure Serverless Functions encompass a range of vulnerabilities specific to Function-as-a-Service (FaaS) platforms such as AWS Lambda, Google Cloud Functions, and Azure Functions. While serverless architectures eliminate many traditional infrastructure security concerns (OS patching, server hardening), they introduce new attack vectors related to function configuration, event-driven triggers, over-privileged execution roles, insecure dependency management, and the expanded attack surface created by diverse event sources that invoke serverless functions.

Serverless functions operate in an ephemeral, event-driven model where each function invocation creates a new execution context (or reuses a warm container) that processes a single event and returns a result. This model shifts security responsibility: the cloud provider secures the underlying infrastructure (shared responsibility model), but the customer remains responsible for function code security, IAM role configuration, event source validation, environment variable protection, and dependency management. Many organizations incorrectly assume that "serverless" means "secure by default."

The event-driven nature of serverless creates a unique attack surface. Functions can be triggered by API Gateway requests, S3 uploads, SQS messages, DynamoDB streams, CloudWatch events, IoT messages, and dozens of other event sources. Each event source provides input data that the function processes, and each represents a potential injection vector. Unlike traditional applications where input enters through well-defined HTTP request parameters, serverless function input arrives through diverse event schemas that developers may not adequately validate.

Attackers exploit insecure serverless functions through several vectors. Over-privileged execution roles are the most common issue: developers assign broad IAM permissions to function roles (e.g., AmazonS3FullAccess, AmazonDynamoDBFullAccess) for development convenience and never narrow them for production. When an attacker exploits an injection vulnerability in the function code, they inherit these excessive permissions and can access any resource the role authorizes, potentially across the entire AWS account.

Injection attacks in serverless functions exploit inadequate input validation on event data. An S3 event trigger that passes the uploaded filename to a shell command is vulnerable to command injection through crafted filenames. An API Gateway event that passes query parameters to a NoSQL query without sanitization is vulnerable to NoSQL injection. A function that processes SQS messages containing user-supplied data may be vulnerable to SQL injection, LDAP injection, or XML external entity (XXE) attacks depending on how the message content is processed. The diverse event sources make it easy for developers to overlook input validation for non-HTTP triggers.

Additional serverless-specific attack vectors include: exploiting environment variables that contain hardcoded secrets (visible to anyone with lambda:GetFunctionConfiguration permission), abusing function URL or API Gateway configurations that lack authentication, manipulating event source mappings to redirect function triggers, exploiting shared /tmp directories in warm function containers to persist malicious payloads between invocations, and supply chain attacks through compromised dependencies in function deployment packages (especially concerning given that serverless functions are rarely scanned with traditional application security tools).

• Cloud resource abuse through over-privileged function roles that provide attackers access to databases, storage, messaging, and other cloud services
• Data exfiltration by exploiting injection vulnerabilities to extract data through function responses, DNS exfiltration, or outbound HTTP requests to attacker-controlled endpoints
• Denial of service through recursive function invocations that create exponential billing (function A triggers function B which triggers function A) or through intentional invocation flooding
• Secret exposure when environment variables containing API keys, database credentials, or encryption keys are accessed through compromised functions or misconfigured IAM policies
• Cross-function lateral movement using compromised function credentials to invoke other functions, modify event source mappings, or update function code
• Financial impact from excessive invocations or resource consumption in pay-per-execution pricing models

1. Apply least-privilege IAM roles to every serverless function. Each function should have a unique execution role with permissions scoped to only the specific resources and actions it needs. Use AWS IAM Access Analyzer or equivalent tools to identify and remove unused permissions. Never share execution roles across functions.
2. Validate and sanitize all input from every event source, not just API Gateway requests. Implement input validation schemas for each event type (S3 events, SQS messages, DynamoDB streams) and reject events that do not conform. Use parameterized queries for all database operations and avoid shell command execution with event-derived input.
3. Use secrets management services (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) instead of environment variables for sensitive configuration. If environment variables must be used, encrypt them with customer-managed KMS keys and restrict GetFunctionConfiguration access.
4. Implement function-level authentication and authorization for all trigger types. API Gateway endpoints should require authentication (IAM, Cognito, custom authorizers). Function URLs should use IAM authentication or be disabled if not needed. S3 event triggers should validate the source bucket and object key patterns.
5. Set appropriate function resource limits: memory allocation, execution timeout (prevent infinite loops), concurrency limits (prevent denial-of-wallet attacks), and payload size limits. Configure dead letter queues for failed invocations to prevent data loss and enable investigation of failed events.
6. Implement dependency scanning and software composition analysis (SCA) for function deployment packages. Use tools like Snyk, Dependabot, or AWS Inspector to identify known vulnerabilities in function dependencies and automate dependency updates.
7. Enable function-level logging and tracing through CloudWatch Logs, X-Ray (AWS), Cloud Logging (GCP), or Application Insights (Azure). Monitor for anomalous invocation patterns, unexpected error rates, unusual execution durations, and outbound network connections to unknown destinations.

Begin by inventorying all serverless functions and their configurations. For AWS, use aws lambda list-functions and aws lambda get-function-configuration to enumerate functions, their execution roles, environment variables, and trigger configurations. Analyze each execution role's effective permissions using IAM policy simulation or tools like Pacu to identify over-privileged functions. Review environment variables for hardcoded secrets.

Test each function's event processing for injection vulnerabilities. Craft malicious payloads appropriate to each event source: for API Gateway triggers, test standard web application injection vectors; for S3 triggers, upload objects with filenames containing shell metacharacters, SQL injection payloads, and path traversal sequences; for SQS triggers, publish messages with injection payloads in message bodies and attributes. Use tools like serverless-artillery or artillery to generate test events at scale.

Assess function authentication and authorization by testing whether functions can be invoked without valid credentials, whether API Gateway endpoints enforce authentication, and whether function URLs are publicly accessible. Test function resource limits by invoking functions with large payloads, triggering recursive invocation chains, and measuring behavior at concurrency limits. Review function deployment packages for vulnerable dependencies using npm audit, pip audit, or dedicated SCA tools. Use cloud-native security tools like AWS Inspector or third-party serverless security platforms to automate comprehensive function security assessment.