CORSpour REST APIs dans API Gateway

Le partage de ressources entre origines (CORS) est une fonctionnalité de sécurité du navigateur qui restreint les HTTP demandes provenant de scripts exécutés dans le navigateur. Pour plus d'informations, voir Qu'est-ce que c'est CORS ? .

Déterminer s'il faut activer le CORS support

Une HTTP demande d'origine croisée est une demande qui est faite 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)

Si vous ne parvenez pas à accéder à votre compte API et que vous recevez un message d'erreur contenant ce messageCross-Origin Request Blocked, vous devrez peut-être l'activerCORS.

HTTPLes demandes provenant de sources multiples peuvent être divisées en deux types : les demandes simples et les demandes non simples.

Permettre CORS une simple demande

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

• Il est émis contre une API ressource qui autorise uniquement GETHEAD, et les POST demandes.

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

• Toutes les exigences supplémentaires répertoriées dans la CORSdocumentation de Mozilla pour les demandes simples.

Pour les demandes de méthode POST d'origine croisée simples, la réponse de votre ressource doit inclure l'en-tête Access-Control-Allow-Origin: '*' ou Access-Control-Allow-Origin:'origin'.

Toutes les autres demandes d'origine croisée ne sont pas des HTTP demandes simples.

Activation CORS d'une demande non simple

Si vos API ressources reçoivent des demandes non simples, vous devez activer un CORS support supplémentaire en fonction de votre type d'intégration.

Activation CORS des intégrations sans proxy

Pour ces intégrations, le CORSprotocole oblige le navigateur à envoyer une demande de prévol au serveur et à attendre l'approbation (ou une demande d'informations d'identification) du serveur avant d'envoyer la demande proprement dite. Vous devez configurer votre appareil API pour envoyer une réponse appropriée à la demande préalable au vol.

Pour créer une réponse en amont :

1. Créez une méthode OPTIONS avec une intégration fictive.

2. Ajoutez les en-têtes de réponse suivants à la réponse de la méthode 200 :

   • Access-Control-Allow-Headers

   • Access-Control-Allow-Methods

   • Access-Control-Allow-Origin

3. Définissez le comportement de transfert de l'intégration surNEVER. Dans ce cas, la demande de méthode d'un type de contenu non mappé sera rejetée avec une réponse HTTP 415 Unsupported Media Type. Pour plus d’informations, consultez Comportements de transfert direct.

4. Entrez des valeurs pour les en-têtes de réponse. Pour autoriser toutes les origines, toutes les méthodes et les en-têtes communs, utilisez les valeurs d'en-tête suivantes :

   • Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'

   • Access-Control-Allow-Methods: '*'

   • Access-Control-Allow-Origin: '*'

Après avoir créé la demande de prévol, vous devez renvoyer l'Access-Control-Allow-Origin:'origin'en-tête Access-Control-Allow-Origin: '*' ou pour toutes les méthodes CORS activées pour au moins les 200 réponses.

Activation CORS des intégrations sans proxy à l'aide du AWS Management Console

Vous pouvez utiliser le AWS Management Console pour activerCORS. APIGateway crée une OPTIONS méthode et ajoute l'Access-Control-Allow-Originen-tête à vos réponses d'intégration de méthodes existantes. Cela ne fonctionne pas toujours et vous devez parfois modifier manuellement la réponse d'intégration pour renvoyer l'Access-Control-Allow-Originen-tête de toutes les méthodes CORS activées pour au moins les 200 réponses.

Activation de la CORS prise en charge des intégrations de proxy

Pour une intégration de proxy Lambda ou une intégration de HTTP proxy, votre backend est chargé de renvoyer les Access-Control-Allow-Headers en-têtesAccess-Control-Allow-Origin, etAccess-Control-Allow-Methods, 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 requis CORS :

Node.js

export const 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!')
    }

Rubriques

• Activer CORS sur une ressource à l'aide de la console API Gateway
• Activer CORS sur une ressource à l'aide de l'importation API Gateway API
• Test CORS d'une API passerelle API