Validating and Verifying API Requests
There are other ways to protect your serverless API beyond the access control mecha‐ nisms 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.
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 Gate‐ way 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.
Implementing request validation via API Gateway can be par‐ ticularly useful when using direct integrations to AWS services other than Lambda. For example, you may have an API Gate‐ way 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).