Comment résoudre les erreurs CORS liées à API Gateway ?

Brève description

Des erreurs CORS (Cross-Origin Resource Sharing) se produisent lorsqu’un serveur ne renvoie pas les en-têtes HTTP requis par la norme CORS. Pour résoudre une erreur CORS liée à une API REST ou à une API HTTP dans API Gateway, vous devez reconfigurer l’API pour qu’elle soit conforme à la norme CORS.

Pour en savoir plus sur la configuration de CORS pour les API REST, consultez la section Activation de CORS pour une ressource d’API REST. Pour les API HTTP, consultez la section Configuration de CORS pour une API HTTP.

Remarque : la fonctionnalité CORS doit être configurée au niveau des ressources et peut être gérée à l’aide de configurations API Gateway ou d’intégrations backend, comme AWS Lambda.

Résolution

L’exemple de procédure suivant montre comment résoudre l’erreur CORS Aucun en-tête "Access-Control-Allow-Origin" présent. Vous pouvez toutefois appliquer une procédure similaire pour résoudre toutes les erreurs CORS. Exemple : erreurs de type Méthode non prise en charge sous l’en-tête Access-Control-Allow-Methods et En-têtes "Access-Control-Allow-Origin" non présents.

Remarque : l’erreur Aucun en-tête "Access-Control-Allow-Origin" présent peut survenir pour l’une des raisons suivantes :

• L’API n’est pas configurée à l’aide d’une méthode OPTIONS qui renvoie les en-têtes CORS requis.
• Un autre type de méthode (tel que GET, PUT ou POST) n’est pas configuré pour renvoyer les en-têtes CORS requis.
• Une API disposant d’une intégration proxy ou non-proxy n’est pas configurée pour renvoyer les en-têtes CORS requis.
• (Pour les API REST privées uniquement) Une URL d’invocation incorrecte est appelée ou le trafic n’est pas acheminé vers le point de terminaison du cloud privé virtuel (VPC) de l’interface.

Confirmation de l’origine de l’erreur

Il existe deux manières de confirmer l’origine d’une erreur CORS liée à API Gateway :

• Créez un fichier d’archive HTTP (HAR) lorsque vous appelez l’API. Confirmez ensuite l’origine de l’erreur dans le fichier en vérifiant les en-têtes des paramètres renvoyés dans la réponse de l’API.
  -ou-
• 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é.

Configuration de CORS sur la ressource d’API qui rencontre l’erreur

Pour les API REST

Suivez les instructions pour l’activation de CORS sur une ressource à l’aide de la console API Gateway.

Pour les API HTTP

Suivez les instructions de la page Configuration de CORS pour une API HTTP.

Important : si vous configurez CORS pour une API HTTP, API Gateway enverra automatiquement une réponse aux demandes OPTIONS avant le contrôle. Cette réponse sera envoyée même si aucun routage OPTIONS n’est configuré pour l’API. Dans le cadre d’une demande CORS, API Gateway ajoute les en-têtes CORS configurés à la réponse provenant d’une intégration.

Veuillez suivre cette étape lorsque vous configurez CORS sur une ressource d’API :

• Dans les réponses de Gateway pour <api-name> l’API, cochez les cases DEFAULT 4XX et DEFAULT 5XX.

Remarque : lorsque vous sélectionnez ces options par défaut, API Gateway répond avec les en-têtes CORS requis, même si la demande n’atteint pas le point de terminaison. Par exemple, si une demande inclut un chemin de ressource incorrect, API Gateway répondra quand même avec une erreur 403 « Jeton d’authentification manquant ».

• Dans Méthodes, cochez la case correspondant à la méthode OPTIONS, si celle-ci n’est pas déjà sélectionnée. Cochez également les cases correspondant à toutes les autres méthodes disponibles pour les demandes CORS. Exemple : GET, PUT et POST.

Remarque : lorsque vous configurez CORS dans la console API Gateway, la méthode OPTIONS est ajoutée à la ressource si elle n’existe pas déjà. La réponse 200 de la méthode OPTIONS est également configurée avec les en-têtes Access-Control-Allow-* requis. Si vous avez déjà configuré CORS à l’aide de la console, toutes les valeurs existantes seront remplacées si vous le configurez à nouveau.

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

Configurez la fonction AWS Lambda backend ou le serveur HTTP pour envoyer les en-têtes CORS requis dans sa réponse. Gardez à l’esprit les points suivants :

• Les domaines autorisés doivent être inclus dans la valeur d’en-tête Access-Control-Allow-Origin sous forme de liste.
• Dans le cadre des 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 le backend de l’API. Dans une intégration de proxy, API Gateway transmet la réponse du backend directement au client.
• Si vous utilisez une intégration non-proxy, vous devez configurer une réponse d’intégration dans API Gateway de façon manuelle pour renvoyer les en-têtes CORS requis.

Remarque : pour les API comportant une intégration non-proxy, les en-têtes CORS requis seront automatiquement ajoutés à la ressource si CORS est configuré sur celle-ci à l’aide de la console API Gateway.

(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 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html#apigateway-private-api-create-interface-vpc-endpoint)point de terminaison d’un VPC d’interface[ associé.

Si le DNS privé est activé

Veillez à invoquer l’API privée depuis votre Virtual Private Cloud (VPC) Amazon en utilisant le nom DNS privé.

Si 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 du VPC.

Remarque : vous devez utiliser l’URL d’invocation suivante, que le DNS privé soit activé ou non :

https://api-id.execute-api.region.amazonaws.com/stage-name

Veillez à remplacer les valeurs des champs api-id, region et stage-name par les valeurs requises pour l’API. Pour en savoir plus, consultez la page Procédure d’invocation d’une API privée.

Important : si CORS est configuré alors que le DNS privé n’est pas activé, vous devez tenir compte des limitations suivantes :

• Vous ne pourrez pas utiliser de noms DNS publics liés à un point de terminaison donné pour accéder à l’API privée depuis votre Amazon VPC.
• Vous ne pourrez pas utiliser l’option d’en-tête Host, car les demandes provenant d’un navigateur n’autorisent pas la manipulation de l’en-tête Host.
• Vous ne pourrez pas utiliser l’en-tête personnalisé x-apigw-api-id, car celui-ci lance une demande 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’atteindront pas votre API.

Informations connexes

Test de CORS

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