Comment résoudre les erreurs HTTP 403 à partir d'API Gateway ?
Dernière mise à jour : 21/11/2022
Lorsque j'appelle mon API Amazon API Gateway, j'obtiens 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 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 :
| 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 une passerelle d'autorisation Lambda API Gateway. |
| 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> » | 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 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. Pour plus d'informations, consultez Comment puis-je résoudre les erreurs 403 « Missing Authentication Token » (Jeton d'authentification manquant) à partir d'un point de terminaison API REST API Gateway ? |
| 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, voir Désactivation du point de terminaison par défaut pour une API REST |
| Appel d'un nom de domaine personnalisé d’une passerelle API 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 puis-je résoudre les erreurs HTTP 403 Forbidden provenant d'un nom de domaine personnalisé d’une passerelle API qui nécessite une authentification TLS mutuelle ? |
| Appel d'un nom de domaine personnalisé sans mappage de chemin de base | "x-amzn-errortype" = "ForbiddenException" |
« Forbidden » (Interdit) | L'appelant appelle un domaine personnalisé sans qu'un chemin de base ne soit mappé à une API.
Pour plus d'informations, consultez Configuration de noms de domaine personnalisés pour les API REST. |
Appel d'une API avec un domaine personnalisé activé lorsque l'URL du domaine inclut la phase |
"x-amzn-errortype" = "MissingAuthenticationTokenException" |
« Missing Authentication Token » (Jeton d'authentification manquant) |
Un mappage d'API spécifie une API, une étape et éventuellement un chemin à utiliser pour le mappage. Par conséquent, lorsque le stage d'une API est mappé à un domaine personnalisé, vous n'avez plus besoin d'inclure le stage dans l'URL. Pour plus d'informations, consultez Utilisation des mappages d'API pour les API REST. |
| L'URL de l'étape de la demande n'est pas valide |
"x-amzn-errortype" = "ForbiddenException" |
« Forbidden » (Interdit) | L'URL de demande de l'appelant inclut une étape qui n'existe pas. Vérifiez que l'étape existe et que l'URL de la demande est orthographiée. Pour plus d'informations, consultez Appel d'une API REST dans Amazon API Gateway. |
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
Cet article vous a-t-il été utile ?
Besoin d'aide pour une question technique ou de facturation ?