Comment résoudre les erreurs HTTP 403 Forbidden (HTTP 403 Accès interdit) à partir d'API Gateway ?
Date de la dernière mise à jour : 10/08/2020
Lorsque j'appelle mon API Amazon API Gateway, je reçois une erreur 403 Forbidden (Interdit). Comment résoudre ces erreurs ?
Brève description
Un code de réponse HTTP 403 signifie qu'un client ne peut pas accéder à une URL valide. Le serveur comprend la demande, mais il ne peut pas traiter pas en raison de problèmes côté client.
Les API API Gateway peuvent renvoyer des réponses 403 Forbidden (Interdit) pour diverses raisons :
| Problème | En-tête de réponse | Message d'erreur | Détails |
|---|---|---|---|
| Access denied (Accès refusé) | "x-amzn-ErrorType" = "AccessDeniedException" | "User is not authorized to access this resource with an explicit deny" | L'appelant n'est pas autorisé à accéder à une API qui utilise un mécanisme d'autorisation Lambda. |
| Access denied (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" | 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. |
| Access denied (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. |
| Access denied (Accès refusé) | "x-amzn-ErrorType" = "AccessDeniedException" | "The security token included in the request is invalid." | L'appelant a utilisé des clés IAM non valides pour accéder à une API utilisant l'autorisation IAM. |
| Missing authentication token (Jeton d'authentification manquant) | "x-amzn-ErrorType" = "MissingAuthenticationTokenException" | "Missing Authentication Token" | Un jeton d'authentification n'a pas été trouvé dans la demande. |
| Authentication token expired (Jeton d'authentification expiré) | "x-amzn-ErrorType" = "InvalidSignatureException" | "Signature expired" | Le jeton d'authentification de la demande a expiré. |
| Invalid API key (Clé API non valide) | "x-amzn-ErrorType" = "ForbiddenException" | "Invalid API Key identifier specified" | L'appelant a utilisé une clé API non valide pour une méthode qui nécessite une clé API. |
| Invalid signature (Signature non valide) | "x-amzn-ErrorType" = "InvalidSignatureException" | "The request signature we calculated does not match the signature you provided. 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 lorsque vous accédez à une API qui utilise l'autorisation IAM. |
| Filtres AWS WAF | "x-amzn-ErrorType" = "ForbiddenException" | "Forbidden" | La demande est bloquée par le filtre du pare-feu d'application web (WAF) lorsque AWS WAF est activé dans l'API. |
| Resource path doesn't exist (Le chemin vers les ressources n'existe pas.) | "x-amzn-ErrorType" = "MissingAuthenticationTokenException" | "Missing Authentication Token" | Une demande sans en-tête « Autorization » est envoyée à un chemin de ressources d'API inexistant. |
| Resource path doesn't exist (Le chemin vers les ressources n'existe pas.) | "x-amzn-ErrorType" = "IncompleteSignatureException" | "Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter. Authorization header requires 'SignedHeaders' parameter. Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header. 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" | Lors de l'appel d'une API privée depuis un Amazon Virtual Private Cloud (Amazon VPC) à l’aide de noms DNS publics, l'en-tête « Host » ou « x-apigw-api-id » est absent de 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 aux points de terminaison. |
Résolution
Suivez ces étapes de dépannage pour vous aider à déterminer la cause de l'erreur.
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, elle peut être provoquée par un paramètre de 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 (par exemple, Amazon CloudFront), ce service peut rejeter la demande avec une erreur 403 dans la réponse.
Activez la journalisation des accès aux API pour analyser le problème.
Vérifiez que la ressource demandée existe dans la définition de l'API
Recherchez la ressource demandée dans l'API à l'aide de la console API Gateway ou de l'interface de ligne de commande AWS (AWS CLI).
Remarque : l'API doit être déployée avec la dernière définition d'API.
Utilisez la commande curl pour obtenir les détails de la demande et de la réponse
Si l'erreur peut être reproduite, vous pouvez utiliser la commande curl -v pour obtenir plus de détails entre le client et l'API. Par exemple :
curl -X GET -v https://apiId.execute-api.region.amazonaws.com/stageName/resourceNamePour plus d'informations sur curl, consultez le site Web du projet curl.
Vérification de l'en-tête
Si l'erreur concerne une clé API, vérifiez que l'en-tête « x-api-key » a été envoyé dans la demande.
Vérification du paramètre DNS sur le point de terminaison d'un VPC
Si l'API est appelée depuis un Amazon VPC qui a un point de terminaison de VPC d'interface, vérifiez que le paramètre DNS du point de terminaison d'interface est défini correctement en fonction du type d'API.
- Pour appeler une API régionale depuis un Amazon VPC, le DNS privé doit être désactivé 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 rubrique Pourquoi l'erreur HTTP 403 Forbidden (HTTP 403 Interdit) est-elle générée lorsque je me connecte à mes API d'API Gateway à partir d'un VPC ?
- Pour appeler une API privée depuis un Amazon VPC à l'aide du nom DNS privé de l'API, le DNS privé doit être activé 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 de l'Amazon VPC. Pour plus d'informations, consultez la rubrique Procédure d'appel d'une API privée.
Remarque : vous n'avez pas besoin d'activer le DNS privé si vous appelez l'API privée à l'aide de son nom DNS public ou d'un alias Amazon Route 53.
Vérification de la stratégie de ressources
Procédez aux vérifications suivantes :
- Si l'API est appelée depuis un Amazon VPC avec un point de terminaison de VPC d'interface, la stratégie de ressources de l'API doit autoriser l'Amazon VPC ou le point de terminaison d'interface à accéder à l'API.
- Les spécifications et le formatage des ressources de la stratégie de ressources sont corrects. (Il n'y a pas de validation de la spécification des ressources lors de l'enregistrement d'une stratégie de ressources.) Pour obtenir des exemples, consultez la rubrique Exemples de stratégies de ressources API Gateway.
Analyse des journaux d'accès à l'API
Activez et analysez les journaux d'accès à l'API pour déterminer si les demandes atteignent l'API.
Analyse des messages de demande et de réponse HTTP
Si vous le pouvez, reproduisez l'erreur dans un navigateur web et utilisez les outils réseau du navigateur pour capturer les messages de demande et de réponse HTTP à des fins d'analyse. Pour une analyse hors connexion, enregistrez ces messages dans un fichier d'archive HTTP (HAR).
Conseil : pour obtenir des instructions sur la création d'un fichier HAR, consultez la rubrique Comment puis-je créer un fichier HAR à partir de mon navigateur pour un cas AWS Support ?
Analysez les demandes et les réponses entre le client et l'API pour trouver où l'erreur s'est produite.
Informations connexes
Cet article vous a-t-il été utile ?
Besoin d'aide pour une question technique ou de facturation ?