Serverless Application Security
Serverless application security addresses the distinct attack surface created when application logic runs in ephemeral, provider-managed execution environments — such as AWS Lambda, Azure Functions, and Google Cloud Functions — rather than on persistent, operator-controlled servers. The model shifts infrastructure responsibility to cloud providers but leaves application-layer security, event validation, and identity controls entirely with the development team. This page covers the definitional scope of serverless security, its operational mechanics, the threat scenarios most common in production deployments, and the decision criteria used to classify and respond to serverless-specific risks.
Definition and scope
Serverless computing, as defined in NIST SP 800-204C, refers to a deployment model in which the cloud provider dynamically allocates execution resources in response to events, with no persistent server instance maintained between invocations. Security responsibility in this model follows the shared responsibility framework: the provider secures the underlying infrastructure, runtime patching, and physical isolation, while the application owner retains full accountability for code integrity, input handling, access control, and secrets management.
The scope of serverless security spans four primary layers:
- Function code — the application logic itself, including dependency chains and third-party packages
- Event sources — HTTP gateways, message queues, object storage triggers, and database streams that invoke functions
- Identity and permissions — IAM roles, execution roles, and resource-level policies governing what a function can access
- Data in transit and at rest — encryption of payloads, environment variables, and downstream storage
Serverless deployments interact directly with cloud-native application security frameworks, and the security posture of a serverless system cannot be evaluated independently of the broader microservices security architecture in which functions typically operate.
The regulatory framing for serverless workloads follows existing application security mandates. PCI DSS v4.0 (PCI Security Standards Council) applies to any function processing cardholder data regardless of deployment model. HIPAA's Security Rule (45 CFR §164.312) requires equivalent technical safeguards for Protected Health Information handled through serverless pipelines as for any other environment.
How it works
Serverless functions are triggered by discrete events — an API Gateway request, an S3 object upload, a message from an SQS queue, or a DynamoDB stream update. Each invocation instantiates a short-lived execution container, runs the function, and terminates or freezes the container. The attack surface this creates differs structurally from traditional web application security.
Execution lifecycle security phases:
- Pre-invocation — Secure the event source: validate authentication tokens, enforce API Gateway authorizers, and restrict triggering principals via resource-based policies.
- Invocation — Validate and sanitize all incoming event data before processing. Event payloads arrive as structured objects (JSON, XML, binary), and every field is an injection vector if untreated — making input validation and output encoding a non-negotiable control.
- Runtime execution — Apply least-privilege IAM roles. AWS recommends one IAM execution role per function, scoped to only the specific resources that function requires. Overpermissive roles — a documented pattern flagged in the OWASP Serverless Top 10 — remain the most prevalent misconfiguration in production serverless environments.
- Post-execution — Audit log all invocations through provider-native logging (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs). Sensitive values must not persist in environment variables without encryption via a dedicated secrets service such as AWS Secrets Manager or HashiCorp Vault.
Contrast with container-based deployments: In container environments (see container and Kubernetes application security), teams manage the OS layer, runtime patching, and network namespace configuration. In serverless, these are abstracted away, reducing the infrastructure attack surface but concentrating risk in the function's event handling logic and IAM configuration. The per-invocation billing model also introduces a denial-of-wallet risk — adversaries who can trigger mass invocations can generate significant cost without causing traditional service disruption.
Static application security testing and software composition analysis integrate into serverless CI/CD pipelines during the build phase to catch vulnerable dependencies before deployment, since function packages bundle their own dependency trees.
Common scenarios
Event injection: Malicious content embedded in event source data — HTTP headers, query strings, S3 object metadata, or SQS message bodies — reaches function code without sanitization. This mirrors injection attack prevention requirements in traditional applications but is amplified by the diversity of serverless event sources.
Overpermissive execution roles: A Lambda function granted s3:* on all buckets instead of read access to a single prefix. The AWS Well-Architected Framework Security Pillar and NIST SP 800-204C both identify least-privilege IAM configuration as a primary serverless control.
Insecure secrets handling: Credentials stored as plaintext environment variables are exposed through provider console access, logging artifacts, and execution context leakage. The OWASP Serverless Top 10 lists insecure secrets storage as a distinct risk category.
Third-party dependency risk: Function packages import npm, PyPI, or Maven packages that may carry known CVEs or be subject to dependency confusion attacks, a supply chain vector documented in NIST SP 800-161r1.
Insecure API Gateway configuration: Functions exposed through HTTP endpoints without authentication, throttling, or WAF integration are directly reachable from the public internet.
Decision boundaries
Classifying serverless security controls requires distinguishing between provider-managed and application-managed responsibility boundaries:
| Control Domain | Provider Responsibility | Application Owner Responsibility |
|---|---|---|
| Runtime patching | Yes | No |
| Network isolation | Partial | Partial (VPC config) |
| IAM role scoping | No | Yes |
| Input validation | No | Yes |
| Secrets encryption | Infrastructure only | Configuration and usage |
| Dependency security | No | Yes |
| Logging enablement | Infrastructure | Application-level logging |
Organizations operating serverless workloads under FedRAMP (fedramp.gov) must verify that cloud service offerings hosting serverless functions carry an active Authorization to Operate (ATO) at the appropriate impact level. Function-level controls remain the application owner's compliance obligation regardless of the provider's ATO status.
Threat modeling for applications applied to serverless systems should enumerate all event sources as trust boundaries, treating each event type as an untrusted input channel. STRIDE-based analysis of serverless architectures maps spoofing threats to API Gateway authentication gaps and elevation-of-privilege threats to IAM role misconfigurations.
References
- NIST SP 800-204C: Implementation of DevSecOps for a Microservices-based Application with Service Mesh
- NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management
- OWASP Serverless Top 10
- AWS Well-Architected Framework — Security Pillar
- PCI Security Standards Council — PCI DSS v4.0
- 45 CFR §164.312 — HIPAA Technical Safeguards (eCFR)
- FedRAMP — Federal Risk and Authorization Management Program