Full Report
Learn about the security risks of misconfigured Lambda function URLs and how to properly secure them.
Analysis Summary
# Best Practices: Securing AWS Lambda Function URLs and Serverless Endpoints
## Overview
These practices address the security risks associated with exposing AWS Lambda functions directly via Function URLs, similar features in other cloud providers (GCP, Azure), or through API Gateways. The primary goal is to prevent unauthorized access, data breaches, privilege escalation, and resource exhaustion (DoS/DoW attacks) stemming from insecurely configured, publicly accessible serverless endpoints.
## Key Recommendations
### Immediate Actions
1. **Disable Unauthenticated Access by Default:** Immediately review all existing Lambda Function URLs and ensure that the resource policy does not authorize invocation by unauthenticated principals (i.e., remove `{"Principal": "*"}`).
2. **Enforce Authentication:** If a Lambda Function URL is required, configure it to require IAM authentication by setting the `Authentication` property to `'AWS_IAM'`.
3. **Review Function Permissions:** For any function URL exposed publicly, audit the associated IAM Role/Service Account to ensure it does *not* possess excessive (high) privileges, especially access to sensitive production data or administrative actions.
4. **Implement Concurrency Limits:** Set a low, reasonable `ReservedConcurrency` limit on functions exposed via public URLs to mitigate Denial of Wallet (DoW) attacks by limiting the maximum number of simultaneous invocations possible.
### Short-term Improvements (1-3 months)
1. **Implement Input Validation:** Update all function code invoked via HTTP/URL endpoints to strictly validate and sanitize all incoming arguments and payload data to prevent injection attacks or information leakage via error messages.
2. **Route Through API Gateway for Complex Needs:** For complex use cases requiring advanced features like custom authorizers, API keys, request validation schemas, or fine-grained throttling, migrate public exposure from direct Function URLs to AWS API Gateway.
3. **Code Scanning for Vulnerabilities:** Integrate automated Static Application Security Testing (SAST) tools into the build pipeline to scan function code dependencies for known Remote Code Execution (RCE) vulnerabilities.
### Long-term Strategy (3+ months)
1. **Establish a Serverless Security Posture Management Program:** Implement continuous monitoring to detect toxic combinations: public exposure $\text{AND}$ lack of authentication $\text{AND}$ high function privileges.
2. **Automated Remediation for Exposure:** Develop automated security guardrails (e.g., using AWS Lambda Event Source Mapping checks or organizational scanning tools) to automatically quarantine or disable any newly deployed function URL found without required IAM authentication.
3. **Define Function-Specific Concurrency Policies:** Analyze the anticipated traffic and business impact for each exposed function to set optimized concurrency limits—low enough to prevent excessive DoW costs, but high enough to support legitimate spikes.
## Implementation Guidance
### For Small Organizations
- Focus primarily on **Immediate Actions** (Disabling anonymous access and enforcing IAM authentication).
- Utilize the built-in SDKs or console features to manage concurrency limits for cost control.
- Adopt a "default deny" approach for all new function deployments unless secured via a configuration mechanism explicitly designed for public access.
### For Medium Organizations
- Implement **Short-term Improvements** by integrating vulnerability scanning into the deployment pipeline for serverless code.
- Standardize on API Gateway for *all* external-facing functions, treating direct Function URLs as strictly ingress for internal/private integration or temporary testing only.
- Document the purpose and required concurrency settings for every exposed endpoint.
### For Large Enterprises
- **Mandate a robust cloud security posture management (CSPM) tool** that can model cloud resource exposure paths like Wiz does, specifically looking for the "toxic combination" of public access, no authentication, and high privileges across Lambda, GCP HTTP, and Azure.
- Formalize a governance process to review and approve any function intended to accept unauthenticated traffic, ensuring strict justification is documented.
- Establish regional concurrency quotas management to prevent cross-service DoS/DoW attacks within your organization's accounts.
## Configuration Examples
Directly securing a Lambda Function URL requires configuration via the AWS console or Infrastructure as Code templates (e.g., CloudFormation, Terraform).
| Configuration Aspect | Desired Secure State | Notes |
| :--- | :--- | :--- |
| **Invoke Mode for URL** | `AWS_IAM` | Ensures only authenticated AWS principals can invoke the function via the URL. |
| **Resource Policy** | Explicitly denies unauthenticated access (`Principal: "*", Effect: "Deny"`) or relies solely on IAM authentication being present. | The default policy allows public access; this must be overridden. |
| **Concurrency Limit** | Set tailored `ReservedConcurrency` value. | Prevents DoW attacks by capping invocation costs. |
| **Function Code** | Includes comprehensive input parsing and returns generic, non-descriptive error messages. | Protects against argument discovery and exploitation via detailed error leaks. |
## Compliance Alignment
- **NIST CSF:** Identify (ID.SC-17), Protect (PR.AC-4, PR.DS-5), Detect (DE.CM-8)
- **ISO 27001/27017:** A.9.2.4 (Access control to system and application files), A.14.2.1 (Secure development policy)
- **CIS Benchmarks (Cloud Specific):** Focus heavily on identity and authorization controls related to public exposure of compute resources.
## Common Pitfalls to Avoid
- **Assuming Protection Through Simplicity:** Do not assume that because a Function URL is simpler than an API Gateway setup, it is inherently secure. It carries the same risks if left unauthenticated.
- **Leaking Information via Errors:** Allowing the function to crash or return detailed stack traces/database errors upon invalid input, which aids attackers in reverse-engineering the required input arguments.
- **Ignoring Concurrency Limits During Testing:** Releasing functions that can handle massive concurrency without setting limits, making them an easy target for DoS/DoW attacks during initial setup.
- **Relying on Function Timeout:** Relying on the function timeout (up to 15 minutes) as the primary defense against running malware (like cryptominers); authentication is the real preventative control.
## Resources
- AWS Lambda Function URLs Documentation (For specific configuration paths)
- AWS IAM Documentation (For configuring roles and preventing high privilege assignments)
- Cloud Security Posture Management (CSPM) tools capable of analyzing Serverless exposure graphs (e.g., Wiz, or native cloud security services).