How to Secure AWS Lambda Function URLs

· Original article ↗

Summary

Misconfigured Lambda function URLs can expose functions to unauthorized access, data changes, service disruption, and unexpected costs. The article recommends IAM authentication and authorization, restrictive CORS settings, and reserved concurrency.

Key points

  • Unauthenticated URLs with permissive resource policies can let attackers invoke functions if they discover the URL and determine the required inputs.
  • Potential impacts include access to or manipulation of data, privilege escalation, exploitation of vulnerable code, denial of service, and increased costs.
  • URLs may be discovered through passive DNS, exposed development artifacts, or existing access to a related environment; obscurity alone is not a sufficient safeguard.
  • Require IAM authentication and limit invocation through IAM policies to specific principals; avoid public or overly permissive policies.
  • Restrict CORS to necessary origins, headers, and methods, but do not treat CORS as a strong security barrier.
  • Set reserved concurrency limits to contain disruption from repeated invocations, balancing service availability against potential cost.

Article Details

Defense Focus
Secure and monitor AWS Lambda function URLs against unauthenticated or overly permissive invocation, excessive privileges, and repeated-invocation disruption.
Detection Methods
  • Use Wiz pre-built Controls and Configuration Rules to identify Lambda functions exposed through a URL, load balancer, or API gateway that lack proper authentication or authorization and have high privileges.
  • Use the Wiz Serverless dashboard to review the security state and related issues across Serverless resources.
  • Monitor for Serverless instances running vulnerable software or infected with malware.
Data Sources
  • Cloud resource exposure, network design, and Lambda function URL configuration
  • Authentication and authorization settings, including IAM identity and resource policies
  • Function privileges and permissions
  • Serverless software vulnerability and malware status
Rule Types
  • Wiz pre-built Controls
  • Wiz Configuration Rules
Platforms
  • Wiz
Defensive Actions
  • Require authentication and authorization for function invocation; use IAM authentication and restrict invocation policies to specific principals.
  • Avoid wildcard principals and public invocation permissions; if unauthenticated invocation is necessary, minimize the function's permissions.
  • Place functions in a private subnet within a VPC; use a NAT gateway in a public subnet when the function requires public internet access.
  • Constrain CORS to specific origins, headers, and HTTP methods, but do not rely on CORS as a standalone security control.
  • Set reserved concurrency limits for functions with URLs to contain disruption, choosing limits that balance denial-of-service and denial-of-wallet risks.
  • Review development artifacts for function URLs or credentials inadvertently left in production.

Malware

Vendors

Products

Related Articles