Comment faire pour corriger les erreurs CORS liées à API Gateway ?

Brève description

Des erreurs Cross-origin resource sharing (CORS) se produisent lorsqu’un serveur ne renvoie pas les en-têtes HTTP requis par la norme CORS. Pour corriger une erreur CORS provenant d’une API REST ou d’une API HTTP de la passerelle API Gateway, vous devez reconfigurer l’API pour qu’elle réponde à la norme CORS.

Remarque : vous devez configurer CORS au niveau des ressources. Utilisez des configurations d’API Gateway ou des intégrations dorsales comme AWS Lambda.

Résolution

Outre l’erreur CORS No 'Access-Control-Allow-Origin' header present, vous pouvez utiliser la procédure suivante pour corriger toutes les erreurs CORS. Parmi les autres erreurs CORS, citons Method not supported under Access-Control-Allow-Methods header et No 'Access-Control-Allow-Headers' headers present.

L’erreur No 'Access-Control-Allow-Origin' header present peut se produire pour les raisons suivantes :

• Vous n’avez pas configuré l’API à l’aide d’une méthode OPTIONS qui renvoie les en-têtes CORS requis.
• Vous n’avez pas configuré d’autres types de méthodes, tels que GET, PUT ou POST, pour renvoyer les en-têtes CORS requis.
• Vous n’avez pas configuré une API avec intégration proxy ou intégration non-proxy pour qu’elle renvoie les en-têtes CORS requis.
• Pour les API REST privées, l’URL d’appel erronée est appelée. Ou alors, le trafic n’est pas acheminé vers le point de terminaison du cloud privé virtuel (VPC) de l’interface.

Confirmer l’origine de l’erreur

Procédez comme suite :

• Créez un fichier d’archive HTTP (HAR) lorsque vous appelez l’API. Vérifiez ensuite les en-têtes de paramètres renvoyés dans la réponse de l’API pour confirmer la cause de l’erreur de fichier.
• Utilisez les outils de développement de votre navigateur pour vérifier les paramètres de demande et de réponse liés à la demande d’API qui a échoué.

Configurer CORS sur la ressource d’API défaillante

Pour les API REST

Suivez les instructions de la section Activer CORS sur une ressource à l’aide de la console d’API Gateway.

Pour les API HTTP

Suivez les instructions de la sectionConfigurer CORS pour une API HTTP.

Lorsque vous configurez CORS sur votre ressource d’API, sélectionnez les options suivantes :

Pour les réponses de la passerelle Gateway, sélectionnez DEFAULT 4XX et DEFAULT 5XX. Lorsque vous sélectionnez **DEFAULT 4XX ** et DEFAULT 5XX, API Gateway répond avec les en-têtes CORS requis même lorsqu’une demande n’atteint pas le point de terminaison. Par exemple, si une demande inclut un chemin de ressource incorrect, API Gateway répond quand même en affichant une erreur 403 « Missing Authentication Token ».

Pour Access-Control-Allow-Methods, si OPTIONS n’est pas déjà sélectionnée, sélectionnez-la ainsi que toutes les autres méthodes disponibles pour les requêtes CORS, telles que GET, PUT, et POST. La console d’API Gateway configure la réponse 200 de la méthode OPTIONS en utilisant les en-têtes Access-Control-Allow requis et remplace les valeurs existantes dans la ressource reconfigurée.

Configuration des intégrations d’API REST pour renvoyer les en-têtes CORS requis

Pour renvoyer les en-têtes CORS requis dans sa réponse, configurez votre fonction Lambda dorsale ou votre serveur HTTP. Vous devez inclure les domaines autorisés dans la valeur d’en-tête Access-Control-Allow-Origin sous forme de liste.

Pour les intégrations de proxy, vous ne pouvez pas configurer de réponse d’intégration dans API Gateway pour modifier les paramètres de réponse renvoyés par la dorsale de votre API. Dans une intégration de proxy, API Gateway transmet la réponse de la dorsale directement au client.

Pour les intégrations sans proxy, vous devez configurer manuellement une réponse d’intégration dans API Gateway pour renvoyer les en-têtes CORS requis. Utilisez la console API Gateway pour configurer CORS, car elle ajoute automatiquement les en-têtes CORS requis à la ressource configurée.

(Pour les API REST privées uniquement) Vérification du paramètre DNS privé du point de terminaison d’interface

Pour les API REST privées, vous devez déterminer si le DNS privé est activé sur le point de terminaison d’un VPC d’interface associé.

Le DNS privé est activé

Utilisez le nom DNS privé pour appeler votre API privée à partir de votre Amazon Virtual Private Cloud (Amazon VPC).

Le DNS privé n’est pas activé

Vous devez acheminer manuellement le trafic depuis l’URL d’invocation vers les adresses IP du point de terminaison d’un VPC. Utilisez l’URL d’appel suivante (alias Route53) :

https://{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage}

Remarque : remplacez rest-api-id, region, vpce-id, et stage par les valeurs de votre API. Pour en savoir plus, consultez Procédure d’invocation d’une API privée.

Si le DNS privé n’est pas activé, vous ne pourrez pas utiliser de noms DNS publics spécifiques au point de terminaison pour accéder à votre API privée à partir de votre Amazon VPC. De plus, vous ne pourrez pas utiliser l’option d’en-tête Host, car les requêtes provenant d’un navigateur n’autorisent pas la modification de l’en-tête Host.

Pour les API privées, vous ne pourrez pas utiliser l’en-tête personnalisé x-apigw-api-id, car il lance une requête OPTIONS avant le contrôle qui n’inclut pas l’en-tête. Les appels d’API qui utilisent l’en-tête x-apigw-api-id n’atteignent pas votre API.

Remarque : assurez-vous que l’autorisation est désactivée dans la méthode OPTIONS de votre API.

Informations connexes

Test de CORS

Activation de CORS sur une ressource à l’aide de l’API d’importation API Gateway