Comment résoudre les erreurs HTTP 403 à partir d'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 répondre à la demande en raison de problèmes côté client.

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

Ré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 des commandes à partir de l'interface de la ligne de commande AWS (AWS CLI), assurez-vous 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, comme dans l’exemple ci-après :

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 Amazon 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 :

• Pour appeler une API régionale depuis un Amazon VPC, les noms DNS privés doivent être désactivés sur le point de terminaison d'interface. Ensuite, le nom d'hôte du point de terminaison peut être résolu par un DNS public. Pour plus d'informations, consultez la section Création d'une API privée dans Amazon API Gateway.
• Pour appeler une API privée depuis un Amazon VPC à l'aide du nom DNS privé de l'API, les noms DNS privés doivent être activés sur le point de terminaison d'interface. Ensuite, le nom d'hôte du point de terminaison d'interface peut être résolu en fonction des ressources de sous-réseau local d'Amazon VPC. Pour plus d'informations, consultez la rubrique Procédure d'appel d'une API privée.
  Remarque : vous n'avez pas besoin de configurer un DNS privé si vous appelez l'API privée à l'aide de l'une des méthodes suivantes :
  Le nom DNS public de l'API privée.
  -ou-
  Un alias Amazon Route 53.

Consultez la politique de ressources de l'API

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

• (Pour les API appelées depuis un Amazon VPC avec un point de terminaison d'un VPC d'interface), la politique de ressources de l'API autorise Amazon VPC ou le point de terminaison d'interface à accéder à l'API.
• Les spécifications et le formatage des ressources de la politique de ressources sont corrects.
  Remarque : il n'y a pas de validation de la spécification des ressources lors de l'enregistrement d'une politique de ressources. Pour obtenir des exemples, consultez Exemples de politiques de ressources API Gateway.
• L'appelant est autorisé à appeler le point de terminaison de l'API selon le type d'authentification que vous avez défini pour l'API. Pour plus d'informations, consultez Comment les politiques de ressources API Gateway affectent le flux de travail d'autorisation.

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).

Informations connexes

Erreurs courantes concernant Amazon API Gateway

Comment puis-je autoriser uniquement des adresses IP spécifiques à accéder à l’API REST de ma passerelle API ?

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

Comment activer Amazon CloudWatch Logs pour résoudre les problèmes liés à l’API REST de ma passerelle API ou à mon API WebSocket ?