Protecting Serverless APIs – Serverless and Security

Heather KetnerLeave a comment

Protecting Serverless APIs

According to the OWASP Top 10 list we looked at earlier in this chapter, the number one threat to web applications is broken access control. While serverless helps to mitigate some of the threats posed by broken access control, you still have work to do in this area.

When applying the zero trust security model, you must apply access control to each isolated component as well as the perimeter of your system. For most serverless applications the security perimeter will be an API Gateway endpoint. If you are building a serverless application that exposes an API to the public internet, you must design and implement an appropriate access control mechanism for this API.

In this section, we’ll explore the available authorization strategies for applying access control to serverless APIs and when to use each one. The access control options for API Gateway are summarized in Table 4-2.

Note

Amazon API Gateway provides two types of APIs: REST APIs and HTTP APIs. They offer different features at different costs. One of the differences is the access control options available. The compatibility for each of the access control methods we’ll explore in this section is indicated in Table 4-2.

Table 4-2. Amazon API Gateway access control options Access control strategyDescriptionREST APIHTTP API
Cognito authorizersDirect integration with the access management service Amazon Cognito and API Gateway REST APIs. Cognito client credentials are exchanged for access tokens, which are validated directly with Cognito.YesNo
JWT authorizersCan be used to integrate an access management service that uses JSON Web Tokens (JWTs) for access control, such as Amazon Cognito or Okta, with API Gateway HTTP APIs.NoaYes
Lambda authorizersLambda functions can be used to implement custom authorization logic when using an access management service other than Cognito or to verify incoming webhook messages where user-based authentication is not available.YesYes
a You can still use JWTs to authorize and authenticate REST API requests, but you will need to write a custom Lambda authorizer that verifies incoming tokens.

Securing HTTP APIs – Serverless and Security

Heather KetnerLeave a comment

Securing HTTP APIs

If you are using an API Gateway HTTP API, rather than a REST API, you will not be able to use the native Cognito authorizer. Instead, you have a few alternative options. We’ll explore examples of the most convenient two: Lambda authorizers and JWT authorizers.

Tip

JWT authorizers can also be used to authenticate API requests with Amazon Cognito when using HTTP APIs.

JWT authorizers

If your authorization strategy simply involves a client submitting a JSON Web Token for verification, using a JWT authorizer will be a good option. When you use a JWT authorizer, the whole authorization process is managed by the API Gateway service.

Note

JWT is an open standard that defines a compact, self-contained way of securely transmitting information between parties as JSON objects. JWTs can be used to ensure the integrity of a message and the authentication of both the message producer and consumer.

JWTs can be cryptographically signed and encrypted, enabling verification of the integrity of the claims contained within the token while keeping those claims hidden from other parties.

You first configure the JWT authorizer and then attach it to a route. The Cloud­For⁠mation resource will look something like this:


{
“Type”
:
“AWS::ApiGatewayV2::Authorizer”
,
“Properties”
:
{
“ApiId”
:
“ApiGatewayId”
,
“AuthorizerType”
:
“JWT”
,
“IdentitySource”
:
[
“$request.header.Authorization”
],
“JwtConfiguration”
:
{
“Audience”
:
[
“https://my-application.com”
],
“Issuer”
:
“https://cognito-idp.us-east-1.amazonaws.com/userPoolID”
},
“Name”
:
“my-authorizer”
}

}

The IdentitySource should match the location of the JWT provided by the client in the API request; for example, the Authorization HTTP header. The Jwt​Config⁠ura⁠tion should correspond to the expected values in the tokens that will be submitted by clients, where the Audience is the HTTP address for the recipient of the token (usually your API Gateway domain) and the Issuer is the HTTP address for the service responsible for issuing tokens, such as Cognito or Okta.

Lambda authorizers – Serverless and Security

Heather KetnerLeave a comment

Lambda authorizers

Lambda functions with custom authorization logic can be attached to API Gateway HTTP API routes and invoked whenever requests are made. These functions are known as Lambda authorizers and can be used when you need to apply access control strategies beyond the ones the managed Cognito or JWT authorizers support. The functions’ responses will either approve or deny access to the requested resources (see Figure 4-6).

Figure 4-6. Controlling access to API Gateway resources with a Lambda authorizer

Lambda authorizers support various locations for providing authorization claims in API requests. These are known as identity sources and include HTTP headers and query string parameters (for example, the Authorization header). The identity source you use will be required in requests made to API Gateway; any requests without the required property will immediately receive a 401 Unauthorized response and the Lambda authorizer will not be invoked.

Lambda authorizer responses can also be cached. The responses will be cached according to the identity source provided by the API’s clients. If a client provides the same values for the required identity sources within the configured cache period, or TTL, API Gateway uses the cached authorizer result instead of invoking the authorizer function.

Tip

Caching the responses of your Lambda authorizers will result in quicker responses to API requests as well as a reduction in costs, as the Lambda function will be invoked significantly less frequently.

The Lambda function used to authorize requests can return an IAM policy or what is known as a simple response. The simple response will usually suffice, unless your use case requires an IAM policy response or more granular permissions. When using the simple response, the authorizer function must return a response matching the following format, where isAuthorized is a Boolean value that denotes the outcome of your authorization checks and context is optional and can include any additional information to pass to API access logs and Lambda functions integrated with the API resource:


{
“isAuthorized”
:
true
/
false
,
“context”
:
{
“key”
:
“value”
}
}

Validating and Verifying API Requests – Serverless and Security

Heather KetnerLeave a comment

Validating and Verifying API Requests

There are other ways to protect your serverless API beyond the access control mechanisms we have explored so far in this section. In particular, publicly accessible APIs should always be protected against deliberate or unintentional misuse and incoming request data to those APIs should always be validated and sanitized.

API Gateway request protection

API Gateway offers two ways of protecting against denial of service and denial of wallet attacks.

First, requests from individual API clients can be throttled via API Gateway usage plans. Usage plans can be used to control access to API stages and methods and to limit the rate of requests made to those methods. By rate limiting API requests, you can prevent any of your API’s clients from deliberately or inadvertently abusing your service. Usage plans can be applied to all methods in an API, or to specific methods. Clients are given a generated API key to include in every request to your API. If a client submits too many requests and is throttled as a result, they will begin to receive 429 Too Many Requests HTTP error responses.

API Gateway also integrates with AWS WAF to provide granular protection at the request level. With WAF, you can specify a set of rules to apply to each incoming request, such as IP address throttling.

Note

WAF rules are always applied before any other access control mechanisms, such as Cognito authorizers or Lambda authorizers.

API Gateway request validation

Requests to API Gateway methods can be validated before being processed further. Say you have a Lambda function attached to an API route that accepts the API request as an input and applies some operations to the request body. You can supply a JSON Schema definition of the expected input structure and format, and API Gateway will apply those data validation rules to the body of a request before invoking the function. If the request fails validation, the function will not be invoked and the client will receive a 400 Bad Request HTTP response.

Note

Implementing request validation via API Gateway can be particularly useful when using direct integrations to AWS services other than Lambda. For example, you may have an API Gateway resource that integrates directly with Amazon EventBridge, responding to API requests by putting events onto an event bus. In this architecture you will always want to validate and sanitize the request payload before forwarding it to downstream consumers.

For more information about functionless integration patterns, refer to Chapter 5.

In the following example JSON model, the message property is required, and the request will be rejected if that field is missing from the request body:


{
“$schema”
:
“http://json-schema.org/draft-07/schema#”
,
“title”
:
“my-request-model”
,
“type”
:
“object”
,
“properties”
:
{
“message”
:
{
“type”
:
“string”
},
“status”
:
{
“type”
:
“string”
}
},
“required”
:
[
“message”
]
}

Deeper input validation and sanitization should be performed in Lambda functions where data is transformed, stored in a database or delivered to an event bus or message queue. This can secure your application from SQL injection attacks, the #3 threat in the OWASP Top 10 (see Table 4-1).

Security in Production – Serverless and Security

Heather KetnerLeave a comment

Security in Production

Making security a part of your development process is key to a holistic security strategy. But what happens when your application is ready for production and, subsequently, running in production?

Going into production can be the most daunting time when it comes to asking yourself the question: is my application secure? To help ease the process, we’ve created a final security checklist to run through before releasing your application to your users that also prepares you to continuously monitor your application for vulnerabilities. Remember, security is a process and something to continually iterate on, just like every other aspect of your software.

Go-Live Security Checklist for Serverless Applications

Here’s a practical list of things to check before launching a serverless application. It can also form part of a security automation pipeline and your team’s security guardrails:

  • Commission penetration testing and security audits early in your application’s development.
  • Enable Block Public Access on all S3 buckets.
  • Enable server-side encryption (SSE) on all S3 buckets containing valuable data.
  • Enable cross-account backups or object replication on S3 buckets containing business-critical data.
  • Enable encryption at rest on all SQS queues.
  • Enable WAF on API Gateway REST APIs with baseline managed rules.
  • Use TLS version 1.2 or above on API Gateway APIs.
  • Enable access and execution logs on API Gateway APIs.
  • Remove sensitive data from Lambda function environment variables.
  • Store secrets in AWS Secrets Manager.
  • Encrypt Lambda function environment variables.
  • Enable Lambda function code signing.
  • Enable backups on all DynamoDB tables containing business-critical data.
  • Scan dependencies for vulnerabilities: resolve all critical and high security warnings, and minimize medium and low warnings.
  • Set up budget alarms in CloudWatch to guard against denial of wallet attacks.
  • Remove any IAM users where possible.
  • Remove wildcards from IAM policies wherever possible to preserve least privilege.
  • Generate an IAM credential report to identify unused roles and users that can be removed.
  • Enable Security Hub reports.
  • Create a CloudTrail trail to send logs to S3.
  • Conduct a Well-Architected Framework review with a focus on the Security pillar and the Serverless Lens’s security recommendations.