Serverless Security: Securing AWS Lambda, Azure Functions & Cloud Functions
On this page
The Serverless Security Paradox
Serverless computing eliminates the patching burden — no servers to manage, no OS to update. But it doesn't eliminate security. It shifts the responsibility from infrastructure security to application and configuration security.
Key Shift: In serverless, you don't manage the server, but you still own the code, the configuration, the IAM permissions, and the data flow. These are where 90% of serverless vulnerabilities live.
Serverless Threat Model
| Threat | Description | Traditional Risk | Serverless Risk |
|---|---|---|---|
| OS/Kernel exploits | Attacking the server operating system | High | Minimal (provider manages) |
| Injection attacks | SQLi, NoSQLi, command injection | High | High (your code, your problem) |
| Over-privileged IAM | Function has more permissions than needed | High | Very High (most common issue) |
| Event injection | Malicious payloads via event sources | N/A | High (new attack vector) |
| Dependency vulnerabilities | Vulnerable libraries in function | High | High (still your deps) |
| Data exposure | Sensitive data in environment vars | Medium | High (common anti-pattern) |
| Denial of wallet | Attacker triggers massive invocations | N/A | High (pay-per-invocation) |
The #1 Serverless Vulnerability: Over-Privileged IAM
Most Lambda functions are deployed with far more permissions than they need:
// BAD — Overly permissive policy (common anti-pattern)
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
// GOOD — Minimum required permissions
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789:table/UserProfiles"
}
IAM Least-Privilege Rules for Serverless:
- One IAM role per function (not shared across functions)
- Specify exact actions (not
dynamodb:*) - Specify exact resource ARNs (not
*) - Use conditions (time-based, IP-based, MFA-required where applicable)
- Audit permissions quarterly with IAM Access Analyzer
Event Injection Attacks
Serverless functions are triggered by events from many sources — each one is an input that must be validated:
| Event Source | Injection Risk | Example Attack |
|---|---|---|
| API Gateway | SQL/NoSQL injection, XSS | Malicious query parameters |
| S3 Bucket | Path traversal, code execution | Malicious filename in event |
| SNS/SQS | Deserialization, injection | Poisoned message payload |
| DynamoDB Streams | Data manipulation | Modified record triggers bad logic |
| CloudWatch Events | None (trusted source) | Minimal risk |
// VULNERABLE — Trusting S3 event data without validation
export const handler = async (event: S3Event) => {
const key = event.Records[0].s3.object.key;
const command = `convert /tmp/${key} /tmp/output.png`;
exec(command); // If key = "file; rm -rf /", command injection!
};
// SECURE — Validate and sanitize event data
export const handler = async (event: S3Event) => {
const key = event.Records[0].s3.object.key;
// Validate the key matches expected pattern
if (!/^uploads\/[a-zA-Z0-9_-]+\.(jpg|png|gif)$/.test(key)) {
throw new Error("Invalid file key");
}
// Use safe API instead of shell command
await sharp(`/tmp/${path.basename(key)}`)
.resize(800, 600)
.toFile("/tmp/output.png");
};
Serverless Security Best Practices
| Practice | Implementation |
|---|---|
| Least-privilege IAM | One role per function, exact actions + resources |
| Input validation | Validate ALL event source data (API, S3, SQS, etc.) |
| Environment variables | Use Secrets Manager, not plaintext env vars for secrets |
| Dependency security | npm audit / Snyk in CI/CD, minimize dependencies |
| Function timeout | Set minimum timeout (prevent infinite loops) |
| Concurrency limits | Set per-function concurrency to prevent denial-of-wallet |
| VPC isolation | Place functions accessing sensitive data in VPC |
| Monitoring | CloudWatch + X-Ray for full invocation tracing |
Denial-of-Wallet Attacks
Unlike traditional DDoS (denial of service), serverless enables denial-of-wallet — attackers trigger massive function invocations to run up your cloud bill.
Prevention:
- Set concurrent execution limits per function
- Set AWS account-level concurrency limits
- Implement budget alerts and auto-shutdown at cost thresholds
- Use WAF with rate limiting on API Gateway
- Monitor invocation anomalies (> 10x baseline = alert)
Further Reading
- OWASP Serverless Top 10 — Serverless-specific risks
- Cloud Security Guide — Multi-cloud security
- IaC Security — Securing serverless infrastructure as code
- Secrets Management — Don't hardcode secrets in Lambda
Published by SecureCodeReviews
This article is part of our original AI security and cybersecurity content library. We show publish and update dates, keep company and policy pages public, and update important guidance when material changes affect readers.
Need a cloud security review before rollout?
We review IAM, network exposure, storage security, deployment posture, and the misconfigurations that usually get missed in fast-moving teams.
Advertisement
Free Security Tools
Try our tools now
Expert Services
Get professional help
OWASP Top 10
Learn the top risks
Related Articles
Cloud Security Guide: AWS, Azure & GCP Misconfigurations 2025
Master cloud security with comprehensive guides on S3 bucket security, IAM policies, secrets management, and real breach case studies.
Cloud Security in 2025: Comprehensive Guide for AWS, Azure & GCP
Deep-dive into cloud security best practices across all three major providers. Covers IAM, network security, data encryption, compliance, and real-world misconfigurations that led to breaches.
How to Secure AI Agents: Identity & Access Management for Agentic AI
Machine identities now outnumber human identities 45:1. Learn how to implement IAM for AI agents — authentication, authorization, credential management, and delegation chains in multi-agent systems.