Creating APIs without authentication unnecessarily increases the attack surface on the target infrastructure.
Unless another authentication method is used, attackers have the opportunity to attempt attacks against the underlying API.
This means attacks
both on the functionality provided by the API and its infrastructure.
Ask Yourself Whether
- The underlying API exposes all of its contents to any anonymous Internet user.
There is a risk if you answered yes to this question.
Recommended Secure Coding Practices
In general, prefer limiting API access to a specific set of people or entities.
AWS provides multiple methods to do so:
-
AWS_IAM, to use standard AWS IAM roles and policies.
-
COGNITO_USER_POOLS, to use customizable OpenID Connect (OIDC) identity providers (IdP).
-
CUSTOM, to use an AWS-independant OIDC provider, glued to the infrastructure with a Lambda authorizer.
Sensitive Code Example
A public API that doesn’t have access control implemented:
AWSTemplateFormatVersion: 2010-09-09
Resources:
ExampleMethod:
Type: AWS::ApiGateway::Method
Properties:
AuthorizationType: NONE # Sensitive
HttpMethod: GET
A Serverless Application Model (SAM) API resource that is public by default:
AWSTemplateFormatVersion: 2010-09-09
Resources:
ExampleApi: # Sensitive
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Compliant Solution
An API that implements AWS IAM permissions:
AWSTemplateFormatVersion: 2010-09-09
Resources:
ExampleMethod:
Type: AWS::ApiGateway::Method
Properties:
AuthorizationType: AWS_IAM
HttpMethod: GET
A Serverless Application Model (SAM) API resource that has to be requested using a key:
AWSTemplateFormatVersion: 2010-09-09
Resources:
ExampleApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Auth:
ApiKeyRequired: true
See
