Comment résoudre les erreurs HTTP 403 Accès interdit à partir d'API Gateway ?

Date de la dernière mise à jour : 19/05/2021

Lorsque j'appelle mon API Amazon API Gateway, je reçois une erreur 403 Accès interdit. Comment puis-je résoudre cette erreur ?

Brève description

Un code de réponse HTTP 403 signifie qu'un client ne peut pas accéder à une URL valide. Le serveur comprend la demande, mais ne peut pas répondre à la demande en raison de problèmes côté client.

Les API API Gateway peuvent renvoyer des réponses 403 Accès interdit pour l'une des raisons suivantes :

Problème En-tête de réponse Message d'erreur Informations
Accès refusé "x-amzn-ErrorType" = "AccessDeniedException" "User is not authorized to access this resource with an explicit deny" L'appelant n'est pas autorisé à accéder à une API qui utilise un mécanisme d'autorisation Lambda.
Access denied (Accès refusé) "x-amzn-ErrorType" = "AccessDeniedException" "User: <user-arn> is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> with an explicit deny"

L'appelant n'est pas autorisé à accéder à une API qui utilise l'autorisation AWS Identity and Access Management (IAM). Ou l'API dispose d'une stratégie de ressources attachée qui refuse explicitement l'accès à l'appelant.

Pour plus d'informations, consultez Stratégie de ressources et d'authentification IAM.

Access denied (Accès refusé) "x-amzn-ErrorType" = "AccessDeniedException" "User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn>"

L'appelant n'est pas autorisé à accéder à une API qui utilise l'autorisation IAM. Ou, l'API dispose d'une stratégie de ressources attachée qui n'autorise pas explicitement l'appelant à appeler l'API.

Pour plus d'informations, consultez Stratégie de ressources et d'authentification IAM.

Access denied (Accès refusé) "x-amzn-ErrorType" = "AccessDeniedException" "The security token included in the request is invalid." L'appelant a utilisé des clés IAM non valides pour accéder à une API utilisant l'autorisation IAM.
Missing authentication token (Jeton d'authentification manquant) "x-amzn-ErrorType" = "MissingAuthenticationTokenException" "Missing Authentication Token" Un jeton d'authentification n'a pas été trouvé dans la demande.
Authentication token expired (Jeton d'authentification expiré) "x-amzn-ErrorType" = "InvalidSignatureException" "Signature expired" Le jeton d'authentification de la demande a expiré.
La clé d'API n'est pas valide "x-amzn-ErrorType" = "ForbiddenException" "Invalid API Key identifier specified" L'appelant a utilisé une clé API non valide pour une méthode qui nécessite une clé API.
La signature n'est pas valide "x-amzn-ErrorType" = "InvalidSignatureException" "The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method." (« La signature de la demande que nous avons calculée ne correspond pas à celle que vous avez fournie. Vérifiez votre clé d'accès secrète et votre méthode de signature. ») La signature de la demande ne correspond pas à celle du serveur lorsque vous accédez à une API qui utilise l'autorisation IAM.
Filtres AWS WAF "x-amzn-ErrorType" = "ForbiddenException" "Interdit" La demande est bloquée par le filtrage du pare-feu d'application Web (WAF) lorsque AWS WAF est activé dans l'API.
Le chemin d'accès à la ressource n'existe pas. "x-amzn-ErrorType" = "MissingAuthenticationTokenException" "Missing Authentication Token" Une demande sans en-tête « Autorization » est envoyée à un chemin de ressources d'API inexistant.
Le chemin d'accès à la ressource n'existe pas. "x-amzn-ErrorType" = "IncompleteSignatureException" "Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter. Authorization header requires 'SignedHeaders' parameter. Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header. Authorization=allow" Une demande avec un en-tête « Authorization » (Autorisation) est envoyée à un chemin de ressources d'API inexistant.
Appel incorrect d'une API privée à l'aide de noms DNS publics "x-amzn-ErrorType" = "ForbiddenException" "Interdit"

Lors de l'appel d'une API privée depuis un Amazon Virtual Private Cloud (Amazon VPC) à l’aide de noms DNS publics, l'en-tête « Host » ou « x-apigw-api-id » est absent de la demande.

Pour plus d'informations, consultez la section Appel de votre API privée à l'aide de noms d'hôte DNS publics spécifiques aux points de terminaison.

Appel d'une API REST qui a un nom de domaine personnalisé à l'aide du point de terminaison eecute-api par défaut.

"x-amzn-ErrorType" = "ForbiddenException" "Interdit"

L'appelant utilise le point de terminaison execute-api par défaut pour appeler une API REST après avoir désactivé le point de terminaison par défaut.

Pour plus d'informations, consultez Désactivation du point de terminaison par défaut pour une API REST.

Résolution

Suivez ces étapes de dépannage pour vous aider à déterminer la cause de l'erreur.

Prenez en compte la source de l'erreur.

Si l'erreur 403 a été signalée à partir d'autres ressources, la cause de l'erreur peut se trouver ailleurs. Par exemple :

  • Si l'erreur a été signalée dans un navigateur Web, cette erreur peut être causée par un paramètre proxy incorrect. Le serveur proxy renvoie une erreur 403 si l'accès HTTP n'est pas autorisé.
  • S'il existe un autre service AWS devant l'API (par exemple, Amazon CloudFront), ce service peut rejeter la demande avec une erreur 403 dans la réponse.

Configurez la journalisation des accès à l'API pour enquêter.

Vérifiez que la ressource demandée existe dans la définition de l'API.

Recherchez la ressource demandée dans l'API à l'aide de la console API Gateway ou de l'interface de ligne de commande AWS (AWS CLI).

Remarque : l'API doit être déployée avec la dernière définition d'API.

Utilisez la commande curl pour obtenir les détails de la demande et de la réponse.

Si l'erreur peut être reproduite, utilisez curl -v pour obtenir plus de détails entre le client et l'API.

exemple de commande curl -v

curl -X GET -v https://apiId.execute-api.region.amazonaws.com/stageName/resourceName

Pour plus d'informations, consultez le site Web du projet curl.

Vérification de l'en-tête

Si l'erreur concerne une clé API, vérifiez que l'en-tête « x-api-key » a été envoyé dans la demande.

Vérification du paramètre DNS sur le point de terminaison d'un VPC

Si l'API est appelée depuis un Amazon VPC qui a un point de terminaison d'un VPC d'interface, vérifiez que le paramètre DNS du point de terminaison d'interface est défini correctement en fonction du type d'API.

Gardez à l'esprit les points suivants :

Vérification de la stratégie de ressources

Vérifiez les points suivants :

  • Si l'API est appelée depuis un Amazon VPC avec un point de terminaison d'un VPC d'interface, la stratégie de ressources de l'API doit autoriser Amazon VPC ou le point de terminaison d'interface à accéder à l'API.
  • Les spécifications et le formatage des ressources de la stratégie de ressources sont corrects. (Il n'y a pas de validation de la spécification des ressources lors de l'enregistrement d'une stratégie de ressources.) Pour obtenir des exemples, consultez la rubrique Exemples de stratégies de ressources API Gateway.

Analyse des journaux d'accès à l'API

Configurez et analysez les journaux d'accès à l'API pour déterminer si les demandes atteignent l'API.

Analyse des messages de demande et de réponse HTTP

Si vous le pouvez, reproduisez l'erreur dans un navigateur Web, puis utilisez les outils réseau du navigateur pour capturer les messages de demande et de réponse HTTP à des fins d'analyse. Pour une analyse hors connexion, enregistrez ces messages dans un fichier d'archive HTTP (HAR).

Remarque : pour obtenir des instructions sur la création d'un fichier HAR, consultez la rubrique Comment puis-je créer un fichier HAR à partir de mon navigateur pour un cas AWS Support ?

Analysez ensuite les demandes et les réponses entre le client et l'API pour déterminer où l'erreur s'est produite.