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

Dernière mise à jour : 04/08/2022

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 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> » (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 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.

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 :

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