Comment puis-je résoudre les erreurs HTTP 403 depuis API Gateway ?

Brève description

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

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

Résolution

Examiner la source de l’erreur

Si l’erreur 403 a été signalée par d’autres ressources, elle peut avoir une autre origine. Par exemple :

• si l’erreur a été signalée dans un navigateur Web, elle peut être due à un mauvais paramétrage du proxy. Le serveur proxy renvoie une erreur 403 si l’accès HTTP n’est pas autorisé.
• S’il existe un autre service AWS en amont de l’API, ce service peut rejeter la demande en envoyant une erreur 403 dans la réponse. Par exemple : Amazon CloudFront.

Identifier 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 atteignent l’API.

Remarque : les API HTTP ne prennent pas en charge la journalisation des exécutions. Pour résoudre les erreurs 403 renvoyées par un nom de domaine personnalisé qui nécessite le protocole TLS mutuel et invoque une API HTTP, vous devez procéder comme suit :

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

2.    Identifiez la cause des erreurs en consultant les journaux d’exécution de votre API REST dans CloudWatch.

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

Confirmez que la ressource demandée existe dans la définition de l’API

Remarque : Si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande AWS (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 passerelle API ou de l’AWS CLI :

• L’API est déployée avec la dernière définition de l’API.
• La ressource demandée existe dans la définition de l’API.

Utiliser 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 suit :

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

**Remarque :**pour obtenir plus d’informations, reportez-vous au site Web du projet curl.

Vérifier que l’en-tête de la requête est correct

Si l’erreur est due à une clé API non valide, vérifiez que l’en-tête « x-api-key » a été envoyé dans la demande.

Vérifier que les paramètres DNS de toute interface des points de terminaison d’un VPC Amazon sont correctement définis

Remarque : vérifiez ce qui suit pour les API invoquées depuis 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 d’interface est correctement défini en fonction du type d’API que vous utilisez.

Gardez à l’esprit les points suivants :

• Pour invoquer une API régionale depuis l’intérieur d’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 en savoir plus, consultez Création d’une API privée dans Amazon API Gateway.
• Pour invoquer une API privée depuis l’intérieur d’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 du sous-réseau local d’Amazon VPC. Pour plus d’informations, consultez Comment invoquer une API privée.
  **Remarque :**il n’est pas nécessaire de configurer un DNS privé si vous invoquez 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.

Passer en revue la politique de ressources d’API

Passez en revue la politique de ressources de votre API pour vérifier les points suivants :

• (Pour les API invoquées depuis un Amazon VPC avec un point de terminaison d’un VPC d’interface) La politique de ressources de l’API accorde à Amazon VPC ou au point de terminaison de l’interface l’accès à l’API.
• Les spécifications et la mise en forme des ressources de la politique de ressources sont correctes.
  Remarque : il n’y a aucune validation de la spécification des ressources lors de l’enregistrement d’une politique de ressources. Pour obtenir des exemples, consultez Exemples de politiques relatives aux ressources d’API Gateway.
• L’appelant est autorisé à invoquer le point de terminaison de l’API par le type d’authentification que vous avez défini pour l’API. Pour plus d’informations, consultez Comment les politiques de ressources de console API affectent le flux de travail d’autorisation.

Examiner 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 recueillir les messages de demande et de réponse HTTP et analysez-les pour déterminer où l’erreur s’est produite.

Remarque : pour une analyse hors ligne, enregistrez les messages dans un fichier HTTP Archive (HAR).

Informations connexes

Erreurs courantes - Amazon API Gateway

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

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

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