# Ensure API Gateway V2 API has an authorizer configured

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292231031888-ensure-api-gateway-v2-api-has-an-authorizer-configured
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that every Amazon API Gateway HTTP or WebSocket API (API Gateway V2) has at least one authorizer defined to authenticate requests. An authorizer, either a JWT authorizer (for example with Amazon Cognito) or a Lambda authorizer, checks the caller's token or request details before the route is invoked. Only the existence of an authorizer on the API is evaluated; whether the routes actually reference the authorizer is not verified.

**Rationale**

Without an authorizer, anyone who knows the API endpoint can invoke its routes. This can expose data, allow unauthorized changes and let automated abuse drive up backend load and costs. Using an authorizer ensures that only authenticated callers can use the API, and scopes, claims or policy decisions can further limit what each caller is allowed to do. Resource policies, throttling and AWS WAF add further layers of protection.

**Impact**

-   Prevents unauthenticated access to API routes and their backends
    
-   Allows access to be limited to specific users, applications or scopes
    
-   Existing clients must send a valid token or credentials once the authorizer is attached to their routes, otherwise their requests are rejected
    
-   Lambda authorizers add latency and Lambda invocation costs
    

**Default Value**

New HTTP and WebSocket APIs have no authorizers, and their routes are created with authorization type NONE.

**Pre-Requisites**

-   IAM permissions: apigateway:GET, apigateway:POST, apigateway:PATCH and apigateway:DELETE on the API, plus lambda:AddPermission when using a Lambda authorizer
    
-   For a JWT authorizer (HTTP APIs only): the token issuer URL and audience, for example from an Amazon Cognito user pool
    
-   For a Lambda authorizer: a Lambda function that validates the request and returns the authorization decision
    
-   A plan for updating API clients to send the required token or credentials
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the API Gateway console and select an HTTP or WebSocket API.
    
3.  Open the authorization or **Authorizers** page of the API and check whether any authorizer exists.
    
4.  Repeat for each API in each region in use.
    
5.  If the API has no authorizer, follow the implementation steps.
    

**CLI:**

List the HTTP and WebSocket APIs:

aws apigatewayv2 get-apis --region <REGION> --query "Items\[\].\[ApiId,Name,ProtocolType\]" --output table

List the authorizers of an API:

aws apigatewayv2 get-authorizers --region <REGION> --api-id <API\_ID> --query "Items\[\].\[AuthorizerId,Name,AuthorizerType\]" --output table

Show which routes use an authorizer, because an authorizer only protects the routes it is attached to:

aws apigatewayv2 get-routes --region <REGION> --api-id <API\_ID> --query "Items\[\].\[RouteKey,AuthorizationType,AuthorizerId\]" --output table

The API fails only if it has no authorizers at all; an API with a defined authorizer passes even if no route references it. Routes with authorization type NONE should therefore also be reviewed, even if the API has an authorizer.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the API Gateway console and select the HTTP or WebSocket API.
    
3.  Open the authorization or **Authorizers** page and create an authorizer:
    
    -   for a JWT authorizer, enter the identity source (for example $request.header.Authorization), the issuer URL and the audience,
        
    -   for a Lambda authorizer, select the Lambda function and the identity source, and allow API Gateway to invoke the function.
        
4.  Attach the authorizer to each route that requires authentication (for WebSocket APIs, to the $connect route).
    
5.  Deploy the API if the stage does not use automatic deployment.
    
6.  Repeat for each affected API in each region in use.
    

**CLI:**

Create a Lambda authorizer for an HTTP API. The payload format version is required for Lambda authorizers on HTTP APIs, so it is added here:

aws apigatewayv2 create-authorizer --region <REGION> --api-id <API\_ID> --authorizer-type REQUEST --name <AUTHORIZER\_NAME> --authorizer-uri arn:aws:apigateway:<REGION>:lambda:path/2015-03-31/functions/<LAMBDA\_FUNCTION\_ARN>/invocations --identity-source '$request.header.Authorization' --authorizer-payload-format-version 2.0 --enable-simple-responses

Allow API Gateway to invoke the authorizer function:

aws lambda add-permission --region <REGION> --function-name <LAMBDA\_FUNCTION\_NAME> --statement-id apigateway-authorizer --action lambda:InvokeFunction --principal apigateway.amazonaws.com --source-arn arn:aws:execute-api:<REGION>:<ACCOUNT\_ID>:<API\_ID>/authorizers/<AUTHORIZER\_ID>

Attach the authorizer to a route:

aws apigatewayv2 update-route --region <REGION> --api-id <API\_ID> --route-id <ROUTE\_ID> --authorization-type CUSTOM --authorizer-id <AUTHORIZER\_ID>

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the API Gateway console and select the API.
    
3.  Detach the authorizer from each route it was attached to.
    
4.  Delete the authorizer if it is no longer needed, and deploy the API if the stage does not use automatic deployment.
    

**CLI:**

aws apigatewayv2 update-route --region <REGION> --api-id <API\_ID> --route-id <ROUTE\_ID> --authorization-type NONE  
aws apigatewayv2 delete-authorizer --region <REGION> --api-id <API\_ID> --authorizer-id <AUTHORIZER\_ID>

Note: rolling back allows anyone to invoke the API routes without authentication again.

**Reference**

-   [https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-access-control.html](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-access-control.html)
    
-   [https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-lambda-authorizer.html)
    
-   [https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-authorizer.html](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-authorizer.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.