Activation de CORS pour une ressource de l'API REST - Amazon API Gateway

Activation de CORS pour une ressource de l'API REST

Le partage des ressources cross-origin (CORS) est une fonctionnalité de sécurité des navigateurs qui restreint les demandes HTTP cross-origin lancées à partir de scripts s'exécutant dans le navigateur. Si les ressources de votre API REST reçoivent des demandes HTTP cross-origine non simples, vous devez activer la prise en charge CORS.

Déterminer s'il convient d'activer la prise en charge de CORS

Une demande HTTP cross-origin est une demande effectuée pour :

  • Un autre domaine (par exemple, de example.com à amazondomains.com)

  • Un autre sous-domaine (par exemple, de example.com à petstore.example.com)

  • Un autre port (par exemple, de example.com à example.com:10777)

  • Un autre protocole (par exemple, de https://example.com à http://example.com)

Les demandes HTTP cross-origin peuvent être réparties en deux types : les demandes simples et les demandes non simples.

Une demande HTTP est simple si toutes les conditions suivantes sont réunies :

  • Elle est émise par rapport à une ressource d'API qui autorise uniquement les demandes GET, HEAD et POST.

  • S'il s'agit d'une demande de la méthode POST, elle doit inclure un en-tête Origin.

  • Le type de contenu de la charge utile de la demande est text/plain, multipart/form-data ou application/x-www-form-urlencoded.

  • La demande ne contient pas d'en-têtes personnalisés.

  • Les exigences supplémentaires répertoriées dans la documentation CORS Mozilla pour les demandes simples.

Pour les demandes de méthode POST cross-origin simples, la réponse de votre ressource doit inclure l'en-tête Access-Control-Allow-Origin, où la valeur de la clé d'en-tête est définie sur '*'(n'importe quelle origine) ou sur les origines autorisées à accéder à cette ressource.

Toutes les autres demandes HTTP cross-origin sont des demandes non simples. Si vos ressources d'API reçoivent des demandes non simples, vous devez activer la prise en charge de CORS.

Que signifie l'activation de la prise en charge de CORS ?

Lorsqu'un navigateur reçoit une demande HTTP non simple, le protocole CORS exige du navigateur qu'il envoie une demande en amont au serveur et attende l'approbation (ou une demande d'informations d'identification) du serveur avant d'envoyer la demande réelle. La demande en amont apparaît à votre API sous la forme d'une demande HTTP qui :

  • inclut un en-tête Origin ;

  • utilise la méthode OPTIONS ;

  • inclut les en-têtes suivants :

    • Access-Control-Request-Method

    • Access-Control-Request-Headers

Pour prendre en charge CORS, par conséquent, une ressource d'API REST doit mettre en œuvre une méthode OPTIONS capable de répondre à la demande en amont OPTIONS avec au moins les en-têtes de réponse suivants mandatés par la norme Fetch :

  • Access-Control-Allow-Methods

  • Access-Control-Allow-Headers

  • Access-Control-Allow-Origin

La façon dont vous activez la prise en charge de CORS dépend du type d'intégration de votre API.

Activation de la prise en charge du CORS pour les intégrations fictives

Dans le cas d'une intégration fictive, vous activez CORS en créant une méthode OPTIONS pour renvoyer les en-têtes de réponse requis (avec les valeurs statiques appropriées) en tant qu'en-têtes de réponse de méthode. En outre, chacune des méthodes réelles pour lesquelles CORS est activé doit également renvoyer l'en-tête Access-Control-Allow-Origin:'request-originating server addresses' dans sa réponse 200 (au moins), où la valeur de la clé d'en-tête est définie sur '*' (n'importe quelle origine) ou sur les origines autorisées à accéder à la ressource.

Activation de la prise en charge de CORS pour des intégrations Lambda de proxy ou de non proxy HTTP et des intégrations de services AWS.

Pour une intégration Lambda personnalisée (non proxy), une intégration personnalisée HTTP (non proxy) ou une intégration de service AWS, vous pouvez configurer les en-têtes requis à l'aide des paramètres de réponse de méthode et d'intégration API Gateway. Lorsque vous activez CORS à l'aide d'AWS Management Console, API Gateway crée une méthode OPTIONS et tente d'ajouter l'en-tête Access-Control-Allow-Origin à vos réponses d'intégration de méthode existantes. Cela ne fonctionne pas toujours, et vous devez parfois modifier manuellement la réponse d'intégration afin d'activer correctement CORS. Généralement, cela consiste simplement à modifier manuellement la réponse d'intégration pour renvoyer l'en-tête Access-Control-Allow-Origin.

Activation de la prise en charge de CORS pour des intégrations Lambda ou des intégrations de proxy HTTP

Pour une intégration de proxy Lambda ou une intégration de proxy HTTP, vous pouvez continuer à configurer les en-têtes de réponse OPTIONS requis dans API Gateway. Toutefois, votre backend est responsable de renvoyer les en-têtes Access-Control-Allow-Origin et Access-Control-Allow-Headers, car une intégration de proxy ne renvoie pas de réponse d'intégration.

Les exemples de fonctions Lambda suivants renvoient les en-têtes CORS requis :

Node.js
exports.handler = async (event) => { const response = { statusCode: 200, headers: { "Access-Control-Allow-Headers" : "Content-Type", "Access-Control-Allow-Origin": "https://www.example.com", "Access-Control-Allow-Methods": "OPTIONS,POST,GET" }, body: JSON.stringify('Hello from Lambda!'), }; return response; };
Python 3
import json def lambda_handler(event, context): return { 'statusCode': 200, 'headers': { 'Access-Control-Allow-Headers': 'Content-Type', 'Access-Control-Allow-Origin': 'https://www.example.com', 'Access-Control-Allow-Methods': 'OPTIONS,POST,GET' }, 'body': json.dumps('Hello from Lambda!') }