As developers focus on building great things, security sometimes takes the backseat. However, with Serverless, we know that developers also work on the infrastructure of using multiple Serverless microservices, while this integration and bringing the microservice with multiple architectural layers with security vision is important.
In this blog, we will look into how security in the Serverless ecosystem is a shared responsibility between AWS and the developer and how one Serverless developer can follow best practices for Lambda security. This could also apply to Cloud in general.
This blog is the extended version of a talk at AWS Community Day DevSecOps Edition Pune 2024 and CorpCon 2025 at Christ University, Bengaluru.
It’s a Shared Responsibility
In the AWS whitepaper, you can learn about “Security and compliance” when building applications with AWS Lambda Functions, a shared responsibility between AWS and the developer/customer for a fully secure application.
The whitepaper showcases how the shared responsibility model is divided with the developer (customer of AWS) taking ownership in the cloud as the code of the Lambda function along with the right resource configurations and the importance of IAM roles and policies while the cloud provider (AWS) takes the responsibility of the cloud by maintaining the infrastructure and environment which Lambda is executed is secure.
A Simple Serverless API
Let’s consider building a simple Serverless API for a CRUD operation invoked from a web app UI. The API is hosted on Amazon API Gateway which triggers a Lambda function to perform CRUD operations on the data in DynamoDB.
Let’s see how the shared responsibility model could be brought into action -
Identity and Access
Code
Data
Infrastructure
Identity and Access
Identity and Access Management (IAM) plays an important role in building the right access control for the AWS Services. For the same Serverless API, let’s understand what are the different IAM permissions needed.
API Gateway endpoints require authorizers for an API used by an application with Identity Pools (IdPs). Authorized users should have an IAM policy that allows them to make API calls to Lambda Functions. The Lambda functions need an IAM execution role to perform SDK API actions with DynamoDB for CRUD operations. While this is a basic example of a simple Serverless API, the architecture can become complex, and the associated IAM policies can also become complicated.
Least Privileges Policy
One mistake that could end up being expensive is wildcard * permissions that allow all actions to a specific or a set of AWS Services, you can follow the best practice of -
Granting only necessary permissions needed for that execution could be by granting access to specific resources along with the Resource ARN, specific API actions only that are required.
Using managed policies for commonly used IAM policies such as DynamoDBCrudPolicy which allows the API Actions - dynamodb:GetItem, dynamodb:DeleteItem, dynamodb:PutItem, dynamodb:Scan, dynamodb:Query, dynamodb:UpdateItem, dynamodb:BatchWriteItem, dynamodb:BatchGetItem, dynamodb:DescribeTable, dynamodb:ConditionCheckItem with the specified DynamoDB table and indexes defined in the table.
Again from the simple Serverless API, the IAM execution role for the Lambda function would look something as below.
Resources:
Users:
Type: AWS::DynamoDB::Table
Properties:
AttributeDefinitions:
- AttributeName: id
AttributeType: S
.
.
PutItemsFunction:
Type: AWS::Serverless::Function
Properties:
.
.
.
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref Users
When using IAM execution policies, allow only what your Lambda code needs blog talks in depth about the least privileges policy.
Code
Security with code in a Serverless application comes into play in the infrastructure layer and also in the application code level.
Enabling Request Validations with Model
When you use API Gateway, it offers Models that define the schema for your request and response. Models help validate the request body and parameters against the schema to ensure the correct parameters are passed with the right data type. This prevents data injections and invalid request body that can break the system.
One such way is defining the Model as part of your application’s IaC code as seen below.
Additionally, when adding the API trigger to the Lambda function, enable Model mapping and configure the request parameters as needed to ensure the correct parameters are passed to the Lambda function.
Using Secrets in the Codebase
One of the best practices in applications is “Not hardcoding credentials and secrets” in your application code base. So, how do you use credentials in your Lambda function code? There are options with Lambda environment variables, Secrets Manager, and Systems Manager Parameter Store.
| Feature | Lambda Environment Variable | Secrets Manager | Systems Manager Parameter Store |
| Data type ⌗ | Key-value pair | Secrets (API keys, credentials, SSH key pairs). | Configurations (environment details) and secrets. |
| Encryption 🔐 | Optional KMS Encryption | Always encrypted with KMS | Optional with SecureString/KMS |
| Key rotation 🔁 | Values updated as per deployments | Built-in key rotation supported | Manual key rotation |
| Size 💾 | 4KB | 64KB | Upto 8KB |
| Cross Account Access 🗝️ | Not even cross-Lambda access | Yes | No |
Among the options for using credentials and secrets, AWS Secrets Manager is the top choice. It provides built-in KMS encryption and supports key rotation, which is essential for any production system. It also offers fine-grain IAM access control.
Check for vulnerability
The codebase often uses third-party libraries and dependencies that can be vulnerable to security issues. One of the easiest ways to protect against vulnerabilities is to keep your packages updated to the latest versions. To do this, you need to scan the codebase. Amazon Inspector can now scan your AWS Lambda functions, detecting affected packages and dependencies that are vulnerable to security issues and providing steps to fix them. Amazon Inspector supports codebase scans, which can be scheduled or run manually with the deployed codebase.
Data
Even in the simple Serverless API, some data is involved either stored in the database or data that is transferred across AWS Services such as Lambda function and API Gateway or through API Gateway to the API client.
Encryption for Data at Rest
AWS Services like Amazon DynamoDB, Amazon Aurora, and Amazon S3 which are data stores support encryption of data at rest with native encryption supported with Amazon Key Management Service (KMS) and also with choice of the customer’s key with KMS.
Encryption for Data in Transit
To ensure data in transit is encrypted and follows secure protocols, use services like SNS and SQS, which support encryption in transit by default. When using Lambda functions with other AWS services, Lambda automatically uses Transport Layer Security (TLS) for data transfers. As part of the shared responsibility model, AWS ensures the security of Lambda's TLS.
Additionally, the HTTPS protocol is used for endpoints exposed by API Gateway and Lambda function URLs, which are managed natively by the API Gateway and Lambda Function Service.
Infrastructure
With Serverless, the infrastructure is maintained by the cloud provider (AWS) and we as developers would also configure things to ensure the infrastructure is maintained well.
Enabling WAF
Web Application Firewall (WAF) ensures the applications are protected from common exploits and abuses such as DDoS attacks, SQL injections, bot traffic, and cross-site scripting, and ensures the underlying AWS resources are not attacked.
As a developer, you can enable WAF for the endpoints created by API services like API Gateway and AppSync to secure API traffic. You can also secure distribution endpoints from CloudFront and S3 web hosting, as well as S3 objects, by enabling WAF.
Throttling and Rate-limits
In addition to making sure web traffic comes from trusted sources, you also need to prevent traffic spikes from overloading your system. API Gateway supports throttling and rate limits for API stages, which can be configured to ensure that traffic spikes don't harm or crash the system.
Bringing It All Together!
For the same Serverless API that performs CRUD operation on DynamoDB and additionally makes API requests to third-party services, let’s apply what we discussed with the security practices.
The web app is hosted on Amazon S3 with the distribution URL enabled with CloudFront and WAF. The web app makes API requests. This ensures the users can securely access the web app.
The API layer with API Gateway has WAF enabled on the endpoint along with the defined usage plan with rate limits and throttling limits. These APIs are authenticated with IAM roles to trigger the Lambda function for execution.
The Lambda function uses VPC to ensure an elastic IP address that can be whitelisted on the third-party service. It also leverages Secrets Manager to store the API credentials of the third-party service and uses IAM to authorize Secrets Manager and DynamoDB access.
Does this sound like too much of an additional overhead for developing a simple Serverless API? Well, security is one of the pillars of the AWS Well-Architected Tool so not an overhead but a practice to follow for all kinds of workloads to ensure better security.
Hope with this blog, you have understood how you are the co-owners of security for the applications when it comes to Serverless (the cloud in general), where as a developer you can implement the recommended best practices with Security.
