Question

Difficulty: MediumTroubleshooting API Gateway Errors and CORS

A frontend web application hosted on `https://app.company.internal` receives a `403 Forbidden` error with the message 'User is not authorized to access this resource' when sending requests to various endpoints of a private Amazon API Gateway REST API. The API uses a custom Lambda Authorizer with caching enabled. The developer notes that the client's first API call to `GET /orders` succeeds, but a subsequent call to `POST /payments` by the same user within a five-minute window fails with the `403 Forbidden` error. The CloudWatch logs show the authorizer executes successfully only for the first request. Which of the following is the most likely cause of this error?

  1. A
    The Lambda Authorizer is configured using Lambda Proxy Integration and failed to format its JSON response with the mandatory keys `statusCode`, `headers`, and `body`.
  2. B
    The REST API is configured with a Cognito User Pool Authorizer, which expects a custom Lambda function to return a JWT token in the authentication response instead of an IAM policy document.
  3. The Lambda Authorizer generated an IAM policy document that hardcoded the specific resource ARN of the first request (`GET /orders`) instead of using wildcards, which was then cached and applied to the subsequent request.Answer
  4. D
    The API Gateway CORS configuration for the `POST` method lacks the `Access-Control-Allow-Origin` header, causing API Gateway to block the request and return a `403 Forbidden` error to the client.

Answer

The Lambda Authorizer generated an IAM policy document that hardcoded the specific resource ARN of the first request instead of using wildcards, which was then cached and applied to the subsequent request.
The correct answer is that the Lambda Authorizer generated a policy document that hardcoded the specific resource ARN of the first request instead of using wildcards, which was then cached and applied to the subsequent request. When authorization caching is enabled, API Gateway caches the policy document returned by the authorizer for the duration of the TTL. If the policy lists a specific resource ARN instead of a wildcard, subsequent requests to different resources or methods using the same cache key will be evaluated against that cached policy and denied with a 403 Forbidden error.

Step-by-Step Solution

1
Analyze the log behavior: the authorizer only runs on the first request and caching is enabled.
Confirm that subsequent requests are authorized using the cached policy statement rather than fresh authorizer execution.
This isolates the failure to how the cached policy document is evaluated by API Gateway for subsequent endpoints.
2
Examine the mismatch between the successful request (`GET /orders`) and the failed request (`POST /payments`).
Determine that the cached policy document must lack permissions for the `POST /payments` resource ARN.
If the authorizer code dynamically generates a policy containing the exact request ARN of the initial request and caching is enabled, subsequent calls to other endpoints with the same token will fail.
3
Identify the proper resolution for this authorization caching behavior.
The authorizer must return a policy resource ARN using wildcards (e.g., `arn:aws:execute-api:region:account-id:api-id/stage/*`) to cover all potential client calls during the cache TTL.
This allows the cached authorization state to apply correctly across different endpoints of the API.

Key Concept

API Gateway Lambda Authorizer Caching and Policy Evaluation
Rate this question