API ゲートウェイからの HTTP 403 エラーをトラブルシューティングする方法を教えてください。

所要時間4分

Amazon API Gateway API を呼び出すと、403 エラーが表示されます。

概要説明

HTTP 403 レスポンスコードは、クライアントが有効な URL へのアクセスを禁止されていることを意味します。サーバーはリクエストを理解していますが、クライアント側の問題のためにリクエストに対応できません。

API ゲートウェイ API は、以下のいずれかの理由で 403 レスポンスを返すことがあります:


問題	レスポンスヘッダー	エラーメッセージ	根本原因
アクセス拒否	"x-amzn-errortype" = "AccessDeniedException"	"User is not authorized to access this resource with an explicit deny"	呼び出し元には、API Gateway Lambda オーソライザーを使用しているAPI にアクセスする権限がありません。
アクセス拒否	"x-amzn-errortype" = "AccessDeniedException"	「ユーザー: <user-arn> execute-api:呼び出しをリソースで実行することが認められていません: <api-resource-arn> 明示的な拒否により」	この呼び出し元には、AWS Identity and Access Management (IAM) 認証を使用する API にアクセスする権限がありません。または、その API には、呼び出し元へのアクセスを明示的に拒否するリソースポリシーが関連付けられています。<br><br>詳細については、「IAM 認証とリソースポリシー」を参照してください。
アクセス拒否	"x-amzn-errortype" = "AccessDeniedException"	"User: anonymous is not authorized to perform: execute-api:Invoke on resource:<api-resource-arn>"	呼び出し元には、IAM 認証を使用している API にアクセスする権限がありません。または、この API には、呼び出し元が API を呼び出すことを明示的に認めないリソースポリシーが関連付けられています。<br><br>詳細については、「IAM 認証とリソースポリシー」を参照してください。
アクセス拒否	"x-amzn-errortype" = "AccessDeniedException"	「リクエストに含まれるセキュリティトークンが無効です。」	呼び出し元が、IAM 認証を使用している API へのアクセスに無効な IAM キーを使用しました。
認証トークンが見つかりません	"x-amzn-errortype" = "MissingAuthenticationTokenException"	「認証トークンが見つかりません」	リクエストに認証トークンが見つかりませんでした。
認証トークンの有効期限が切れました	"x-amzn-errortype" = "InvalidSignatureException"	「署名の有効期限が切れました」	リクエストの認証トークンの有効期限が切れています。
API キーが無効です	"x-amzn-errortype" = "ForbiddenException"	「無効な API キー識別子が指定されました」	呼び出し元が、API キーを必要とする方法では有効ではない API キーを使用しました。
署名は無効です	"x-amzn-errortype" = "InvalidSignatureException"	「計算したリクエストの署名が、提供された署名と一致しません。AWS シークレットアクセスキーと署名方法を確認してください。」	IAM 認証を使用している API にアクセスするときに、リクエストの署名がサーバー上の署名と一致しません。
AWS WAF フィルタリング	"x-amzn-errortype" = "ForbiddenException"	「禁止」	API で AWS WAF をアクティブにすると、リクエストはウェブアプリケーションファイアウォールのフィルタリングによってブロックされます。
リソースパスが存在しません	"x-amzn-errortype" = "MissingAuthenticationTokenException"	「認証トークンが見つかりません」	「Authorization」ヘッダーがないリクエストは、存在しない API リソースパスに送信されます。<br><br>詳細については、「API ゲートウェイ REST API エンドポイントで発生した 403「認証トークンが見つかりません」エラーをトラブルシューティングする方法を教えてください」を参照してください。
リソースパスが存在しません	"x-amzn-errortype" = "IncompleteSignatureException"	『認証ヘッダーには 'Credential' パラメーターが必要です。認証ヘッダーには 'Signature' パラメーターが必要です。認証ヘッダーには 'SignedHeaders' パラメーターが必要です。認証ヘッダーには 'X-Amz-Date' または 'Date' ヘッダーが必要です。Authorization=allow"	"Authorization" ヘッダーがあるリクエストは、存在しない API リソースパスに送信されます。
パブリック DNS 名によるプライベート API の不正呼び出し	"x-amzn-errortype" = "ForbiddenException"	「禁止」	パブリック DNS 名による Amazon Virtual Private Cloud (Amazon VPC) 内からのプライベート API の不正呼び出し。例: リクエストに "Host" ヘッダーまたは "x-apigw-api-id" ヘッダーがありません。<br><br>詳細については、「エンドポイント固有のパブリック DNS ホスト名によるプライベート API の呼び出し」を参照してください。
デフォルトの execute-api エンドポイントによる、カスタムドメイン名を持つ REST API の呼び出し	"x-amzn-errortype" = "ForbiddenException"	「禁止」	呼び出し側は、デフォルトエンドポイントを非アクティブにした後に、デフォルトの execute-api エンドポイントを使用して REST API を呼び出します。<br><br>詳細については、「REST API のデフォルトエンドポイントの無効化」を参照してください。
無効なクライアント証明書による、相互 Transport Layer Security (TLS) が必要な API Gateway カスタムドメイン名の呼び出し。	"x-amzn-errortype" = "ForbiddenException"	「禁止」	API リクエストで提示されたクライアント証明書は、カスタムドメイン名のトラストストアによって発行されていないか、有効ではありません。<br><br>詳細については、「相互 TLS が必要な API Gateway カスタムドメイン名からの HTTP 403 禁止エラーのトラブルシューティング方法を教えてください」を参照してください。
ベースパスマッピングなしでのカスタムドメイン名の呼び出し	"x-amzn-errortype" = "ForbiddenException"	「禁止」	呼び出し側は、ベースパスが API にマップされていない状態でカスタムドメインを呼び出します。<br><br>詳細については、「REST API 用のカスタムドメイン名の設定」を参照してください。
ドメイン URL にステージが含まれている場合にカスタムドメインを有効にした API の呼び出し	"x-amzn-errortype" = "MissingAuthenticationTokenException"	「認証トークンが見つかりません」	API マッピングでは、API、ステージ、およびオプションでマッピングに使用するパスを指定します。そのため、API のステージをカスタムドメインにマップすると、URL にステージを含める必要がなくなります。<br><br>詳細については、「REST API の API マッピングの使用」を参照してください。
リクエスト URL のステージは無効です	"x-amzn-errortype" = "ForbiddenException"	「禁止」	呼び出し元のリクエスト URL に、存在しないステージがあります。ステージが存在することを確認し、リクエスト URL のスペルを確認してください。<br><br>詳細については、「Amazon API ゲートウェイでの REST API の呼び出し」を参照してください。

解決策

エラーの原因を検討してください

403 エラーが他のリソースから報告された場合は、別の原因が考えられます。例:

エラーが Web ブラウザで報告された場合、プロキシ設定が正しくないことがそのエラーの原因である可能性があります。HTTP アクセスが認められていない場合、プロキシサーバーは 403 エラーを返します。
API の前に別の AWS サービスがある場合、レスポンスに 403 エラーでそのサービスがリクエストを拒否する場合があります。例: Amazon CloudFront。

エラーの原因を特定する

API の Amazon CloudWatch アクセスロギングのセットアップがまだであれば、実行してください。次に、CloudWatch で API の実行ログを表示して、リクエストが API に届いているかどうかを確認します。

注:HTTP API は実行ログをサポートしていません。相互 TLS を必要とし、HTTP APIを呼び出すカスタムドメイン名によって返される 403 エラーをトラブルシューティングするには、以下の手順を実行する必要があります:

1. テスト専用の REST API を呼び出すカスタムドメイン名の新しい API マッピングを作成します。

2. CloudWatch の REST API の実行ログを確認して、エラーの原因を特定してください。

3. エラーを特定して解決できたら、あなたの HTTP API にカスタムドメイン名の API マッピングを再ルーティングします。

要求されたリソースが API 定義に存在することを確認する

**注:**AWS Command Line Interface (AWS CLI) コマンドの実行時にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。

API Gateway コンソールまたは AWS CLI で以下の内容を確認してください:

API は最新の API 定義でデプロイされている。
要求されたリソースが API 定義に存在する。

curl でリクエストとレスポンスの詳細を取得する

エラーが再現できる場合は、curl-v コマンドで、次のようなクライアントと API 間の詳細情報を取得します。

curl -X HTTP_VERB -v https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}

**注:**詳細については、「curl プロジェクトのウェブサイト」を参照してください。

リクエストヘッダーが正しいことを確認する

無効なAPI キーがエラーの原因である場合は、リクエストで "x-api-key" ヘッダーが送信されたことを確認してください。

すべてのインターフェイスの Amazon VPC エンドポイントの DNS 設定が正しく設定されていることを確認してください。

注:インターフェイス VPC エンドポイントのみがある Amazon VPC から呼び出された API については、以下の内容を確認してください。

インターフェイスエンドポイントの DNS 設定が、使用している API のタイプに基づいて正しく設定されていることを確認してください。

次の点に注意してください:

Amazon VPC 内からリージョン API を呼び出すには、インターフェイスエンドポイントでプライベート DNS 名を非アクティブにする必要があります。これで、エンドポイントのホスト名をパブリック DNS で解決できます。詳細については、「Amazon API Gateway でのプライベート API の作成」を参照してください。
Amazon VPC 内から API のプライベート DNS 名でプライベート API を呼び出すには、インターフェイスエンドポイントでプライベート DNS 名をアクティブにする必要があります。次に、インターフェイスエンドポイントのホスト名を Amazon VPC のローカルサブネットリソースに解決できます。詳細については、「プライベート API を呼び出す方法」を参照してください。
注: 次のいずれかを使用してプライベート API を呼び出す場合は、プライベート DNS を設定する必要はありません:
プライベート API のパブリック DNS 名。
-or-
Amazon Route 53 エイリアス。

API のリソースポリシーを確認します

API のリソースポリシーで、以下の内容を確認してください:

(インターフェイス VPC エンドポイントで Amazon VPC から呼び出された API の場合) API のリソースポリシーで、Amazon VPC またはインターフェイスエンドポイントアクセスが API に認められいる。
リソースポリシーのリソース仕様と書式が正しい。
注: リソースポリシーを保存するとき、リソース仕様の検証は行われません。例については、API Gateway リソースポリシーの例を参照してください。
呼び出し元は、API に定義した認証タイプ別に API エンドポイントを呼び出すことができます。詳細については、「API Gateway リソースポリシーが承認ワークフローに与える影響」を参照してください。

HTTP リクエストとレスポンスメッセージを見直す

可能であれば、Web ブラウザでエラーを再現してください。次に、ブラウザーのネットワークツールで HTTP リクエストメッセージとレスポンスメッセージを取得し、それらを分析してエラーが発生した場所を特定します。

**注:**オフライン分析では、HTTP アーカイブ (HAR) ファイルにメッセージを保存します。