Comment résoudre les erreurs HTTP 403 à partir de API Gateway ?

Dernière mise à jour : 16-12-2021

Lorsque j'appelle mon API Amazon API Gateway, je reçois une erreur 403. Comment résoudre les erreurs 403 à partir de API Gateway ?

Brève description

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

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

Problème En-tête de réponse Message d'erreur Cause racine
Accès refusé "x-amzn-errortype" = "AccessDeniedException" « User is not authorized to access this resource with an explicit deny » (L'utilisateur n'est pas autorisé à accéder à cette ressource avec un refus explicite) L'appelant n'est pas autorisé à accéder à une API qui utilise un mécanisme d'autorisation Lambda.
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 » (User: <user-arn> n'est pas autorisé à effectuer: execute-api:Invoke sur la ressource: <api-resource-arn> avec un refus explicite)

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.
Accès refusé "x-amzn-errortype" = "AccessDeniedException" « User: anonymous is not authorized to perform: execute-api:Invoke on resource: <api-resource-arn> » (User: anonymous n'est pas autorisé à exécuter: 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.
Accès refusé "x-amzn-errortype" = "AccessDeniedException" « The security token included in the request is invalid. » (Le jeton de sécurité inclus dans la demande n'est pas valide.) L'appelant a utilisé des clés IAM non valides pour accéder à une API qui utilise l'autorisation IAM.
Jeton d'authentification manquant "x-amzn-errortype" = "MissingAuthenticationTokenException" « Missing Authentication Token » (Jeton d'authentification manquant) Un jeton d'authentification n'a pas été trouvé dans la demande.
Jeton d'authentification expiré "x-amzn-errortype" = "InvalidSignatureException" « Signature expired » (Signature expirée) 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 » (Identifiant de clé API non valide spécifié) L'appelant a utilisé une clé API qui n'est pas 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. » (La signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie.) 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 lors de l'accès à une API qui utilise l'autorisation IAM.
Filtres AWS WAF "x-amzn-errortype" = "ForbiddenException" « Forbidden » (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 » (Jeton d'authentification manquant) 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. » (L'en-tête d'autorisation requiert le paramètre « Credential » (Informations d'identification).) L'en-tête d'autorisation requiert le paramètre « Signature » (Signature). L'en-tête d'autorisation requiert le paramètre « SignedHeaders ». L'en-tête d'autorisation requiert l'existence d'un en-tête « X-Amz-Date » ou « Date ». 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" « Forbidden » (Interdit)

Appel d'une API privée depuis un Amazon Virtual Private Cloud (Amazon VPC) avec des noms DNS publics incorrects. Par exemple : l'en-tête « Host » ou « x-apigw-api-id » est manquant dans 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 au point 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" « Forbidden » (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.
Appel d'un nom de domaine personnalisé API Gateway qui nécessite un protocole TLS (Transport Layer Security) mutuel à l'aide d'un certificat client qui n'est pas valide. "x-amzn-errortype" = "ForbiddenException" « Forbidden » (Interdit)

Le certificat client présenté dans la demande d'API n'est pas émis par le magasin de confiance du nom de domaine personnalisé, ou il n'est pas valide.

Pour plus d'informations, consultez Comment dois-je résoudre les erreurs HTTP 403 Forbidden provenant d'un nom de domaine personnalisé d'API Gateway qui nécessite une authentification TLS mutuelle ?

Solution

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, ce service peut alors rejeter la demande avec une erreur 403 dans la réponse. Par exemple : Amazon CloudFront.

Identifiez la cause de l'erreur

Si ce n'est pas déjà fait, configurez la journalisation des accès Amazon CloudWatch pour votre API. Consultez ensuite les journaux d'exécution de votre API dans CloudWatch pour déterminer si les demandes parviennent à l'API.

Remarque : les API HTTP ne prennent pas en charge la journalisation d'exécution. Pour résoudre les erreurs 403 renvoyées par un nom de domaine personnalisé qui nécessite une authentification TLS mutuelle et appelle une API HTTP, vous devez procéder comme suit :

1.    Créez un mappage d'API pour votre nom de domaine personnalisé qui appelle une API REST uniquement à des fins de test.

2.    Identifiez la cause des erreurs en consultant vos journaux d'exécution de l'API REST dans CloudWatch.

3.    Une fois l'erreur identifiée et résolue, redirigez le mappage d'API pour votre nom de domaine personnalisé vers votre API HTTP.

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

Remarque : si vous recevez des erreurs lors de l'exécution de commandes depuis AWS Command Line Interface (AWS CLI), vérifiez que vous utilisez la version la plus récente d'AWS CLI.

Vérifiez les points suivants à l'aide de la console API Gateway ou de l'AWS CLI :

  • L'API est déployée avec la dernière définition d'API.
  • La ressource demandée existe dans la définition de l'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 la commande curl -v pour obtenir plus de détails entre le client et l'API.

exemple de commande curl -v

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

Remarque : pour plus d'informations, consultez le site web du projet curl.

Vérifiez que l'en-tête de demande est correct

Si l'erreur est le résultat d'une clé d'API non valide, vérifiez que l'en-tête « x-api-key » a été envoyé dans la demande.

Vérifiez que le paramètre DNS sur les points de terminaison d'un VPC d'interface est correctement défini.

Remarque : confirmez ce qui suit pour les API appelées à partir d'un Amazon VPC doté d'un point de terminaison d'un VPC d'interface uniquement.

Vérifiez que le paramètre DNS du point de terminaison de l'interface est correctement défini en fonction du type d'API que vous utilisez.

Gardez à l'esprit les points suivants :

Consultez la politique de ressources de l'API

Consultez la politique de ressources de votre API pour vérifier les points suivants :

Analysez les messages de demande et de réponse HTTP

Reproduisez l'erreur dans un navigateur web, si possible. Ensuite, utilisez les outils réseau du navigateur pour capturer les messages de demande et de réponse HTTP et analysez-les afin de déterminer où l'erreur s'est produite.

Remarque : pour une analyse hors connexion, enregistrez les messages dans un fichier d'archive HTTP (HAR).

Gestion des erreurs dans Amazon API Gateway

Comment puis-je autoriser uniquement des adresses IP spécifiques à accéder à mon API REST API Gateway ?

Comment résoudre les problèmes de connexion à un point de terminaison d'une API privée d'API Gateway ?

Comment activer Amazon CloudWatch Logs pour résoudre les problèmes liés à mon API REST API Gateway ou à mon API WebSocket ?

Cet article vous a-t-il été utile ?

Envoyer un commentaire

Avez-vous besoin d'aide pour une question technique ou de facturation ?

Contactez AWS Support