API Gateway Security
Learn how to enforce secure and precise access to the APIs by applying the right access controls at each layer.
Once an API is deployed and observable, securing it becomes critical. API Gateway offers multiple mechanisms to protect endpoints against unauthorized or unintended access. These mechanisms can be layered together to form a robust access control strategy depending on the API type (HTTP, REST, and WebSocket) and its intended consumers.
We’ll now explore each mechanism individually, organized by how they integrate with IAM, token-based identity, WebSocket connection control, and network-level protection.
IAM-based authorization
For internal applications or backend services hosted in AWS, IAM provides native access control to API Gateway. IAM policies can be used to define fine-grained access to specific resources or HTTP methods.
Method-level authorization
When securing our API Gateway, we're not limited to global access controls. Method-level authorization lets us apply different permissions to individual resources or HTTP methods (like, GET /items
, POST /items
). This works in conjunction with IAM policies and resource policies to offer fine-grained access control.
For example, we can attach an IAM policy that allows a specific role to invoke only the GET
method on a specific resource path:
{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "execute-api:Invoke","Resource": "arn:aws:execute-api:us-east-1:123456789012:abc123/prod/GET/items"}]}
In cross-account scenarios, the IAM role assumed by a different AWS account must also have permissions to invoke the method, and the API’s resource policy must allow the caller’s AWS account.
Similarly, when API Gateway integrates with a Lambda function, it invokes the function, but the Lambda executes under its own IAM role. This role governs what the function can access, such as reading from DynamoDB or writing to S3. ...