Serverless architecture accelerates development and reduces infrastructure management, but it also introduces security blind spots that traditional tools often fail to detect.
AWS Lambda, API Gateway, and DynamoDB have revolutionized application development, eliminating infrastructure concerns and creating new security challenges. Additionally, AWS serverless security pitfalls that compliance checklists often overlook.
Cloud providers are increasingly seeing businesses adopt serverless security. One study reports that 70% of AWS customers, 60% of Google Cloud customers, and 49% of Azure customers are using serverless security in some capacity.
However, the event-driven, ephemeral, and permission-restricted nature doesn’t automatically make them secure. Misconfigurations, poor access controls, and overlooked security practices still leave gaps that attackers can exploit.
Here’s what you need to know about the leading serverless security traps, complete with real-world misconfigurations, attack scenarios, and step-by-step fixes to help you protect your functions before attackers exploit them.
1. Overprivileged IAM Roles
AWS IAM (Identity and Access Management) roles define what resources a Lambda function can access and are crucial to AWS security.
However, since serverless functions interact with multiple AWS services, S3, DynamoDB, and RDS, unfortunately, developers often assign overly broad permissions for convenience.
For example, a developer may grant a Lambda function full access to S3:
// BAD: Lambda role with wildcard S3 access
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
Why It’s Dangerous
When a Lambda function is granted excessive permissions, it creates an easy pathway for attackers to escalate their access if they manage to compromise the function. Attackers who gain access to a function with broad permissions can steal temporary AWS credentials, allowing them to interact with other AWS services undetected.
If exploited, this vulnerability could lead to unauthorized access to sensitive data stored in S3, unauthorized database modifications, or even infrastructure takeovers if IAM policies permit actions on EC2 or RDS.
While that’s harmful, the more severe risk is lateral movement. Once an attacker has a foothold in the environment, they can explore misconfigurations in other AWS services, increasing the blast radius of a breach.
How to Fix It
The most effective approach to mitigating this risk is following the principle of least privilege by ensuring that each Lambda function has only the permissions it strictly requires to carry out its task. Instead of granting wildcard access, define specific resources and actions:
// FIX: Restrict Lambda access to a single bucket
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-secure-bucket/*"
}
Developers should also use IAM conditions to limit access based on execution context. Regular audits using AWS IAM get-role-policy can help detect excessive permissions early, preventing misconfigurations from slipping into production.
2. Poisoned Dependencies
While dependencies accelerate development, they also introduce significant risks when outdated or vulnerable dependencies are included without a thorough review.
Lambda functions often depend on external packages pulled from npm (Node.js), PyPI (Python), or other repositories. This dependency can introduce vulnerabilities outside the attack surface you’re monitoring.
Example of an insecure package.json:
// HIGH-RISK package.json
"dependencies": {
"lodash": "4.17.15" // CVE-2021-23337
}
Why It’s Dangerous
If a Lambda function relies on a compromised package, attackers can execute arbitrary code, exfiltrate sensitive data, or even take control of the execution environment. Older dependencies can also lead to supply chain attacks, where attackers insert malicious code into popular open-source libraries.
Traditional vulnerability scanners often miss these risks because serverless functions execute in ephemeral environments, making runtime inspection difficult.
How to Fix It
To reduce the risk of poisoned dependencies, developers should integrate automated dependency scanning into their CI/CD pipeline.
Tools like npm audit or AWS CodeGuru can identify known vulnerabilities before deployment. Versioning should also be managed carefully by avoiding wildcard or unpinned versions (“lodash”: “4.17.*”) to prevent accidental updates to insecure versions.
Additionally, using Lambda layers responsibly by only including essential dependencies can reduce the attack surface and minimize risks.
3. Plaintext Secrets in Environment Variables
Developers often store sensitive credentials in plaintext environment variables rather than using AWS Secrets Manager for easy access. This creates an avoidable vulnerability that doesn’t require complex integrations.
Example of a high-risk configuration:
# RISKY Lambda environment
import os
DB_PASSWORD = os.environ['prod_db_pass'] # Plaintext!
Why It’s Dangerous
Storing secrets in environment variables makes them vulnerable to accidental exposure in logs or retrieval via the AWS CLI. Debugging logs may inadvertently capture secret values, allowing anyone accessing CloudWatch logs to retrieve them.
Attackers who gain AWS CLI access can extract environment variables using a single command:
aws lambda get-function-configuration --function-name MyLambda
Once credentials are exposed, they can be used to connect to databases, cloud storage, or other AWS services, leading to widespread compromise.
How to Fix It
Instead of hardcoding secrets, use AWS Secrets Manager, which encrypts and securely retrieves credentials when needed. This can be done with only a few lines of code:
import boto3
client = boto3.client('secretsmanager')
secret = client.get_secret_value(SecretId='prod/db/password')
AWS KMS (Key Management Service) should be used to encrypt sensitive data at rest. Finally, IAM policies should be configured to restrict access to secret retrieval, ensuring that only the necessary functions have permission to decrypt and use secrets.
4. Unlocked API Gateways
Many developers unintentionally expose Lambda functions by misconfiguring API Gateway settings. If an API is left unauthenticated, anyone on the internet can access it.
Example of a risky serverless configuration:
# serverless.yml - DANGEROUS configuration
functions:
userData:
handler: handler.getUser
events:
- httpApi:
path: /user/{id}
method: GET
# MISSING authorizer!
Why It’s Dangerous
An exposed API Gateway allows attackers to access backend resources without authentication, leading to data leaks, unauthorized transactions, and business logic exploitation.
This means that attackers can automate requests, extract large amounts of data, and exploit missing rate limits to overload backend systems, which can then cause availability issues.
How to Fix It
Every API endpoint should have authentication and authorization controls. Developers should integrate JWT-based authentication using Amazon Cognito or OAuth providers.
API Gateway rate limiting and Web Application Firewall (WAF) protections should be enabled to prevent abuse. IAM authentication should be enforced for internal APIs to restrict access to trusted users and services.
Adopt the Serverless Security Mindset with Tamnoon
AWS serverless security requires a proactive approach, embedding security controls at multiple layers. Otherwise, you may introduce entirely new vulnerabilities to your ecosystem that may not be immediately obvious.
Before deployment, IAM roles should be hardened, dependencies audited, and API authentication enforced. At runtime, anomalies should be detected, execution privileges should be minimized, and logs should be continuously monitored for suspicious activity.
Serverless computing regenerates its attack surface with every deployment. Developers can mitigate risks by adopting a shift-left security approach, securing dependencies, enforcing permissions, and locking down APIs before they escalate.
Managing serverless security while managing the rest of your infrastructure and ecosystem can be challenging. Fortunately, Tamnoon has your back.
We offer managed or assisted cloud security remediation that blends the best of AI with battle-tested human expertise so you can focus on what matters most. Book a demo today to discover how to help prevent cyber attacks enabled by preventable vulnerabilities.
Final Tip: Run the AWS IAM simulate-principal-policy to test Lambda permissions. You might be surprised at what they can access!
