Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# CORS pour REST APIs dans API Gateway
Le [partage des ressources entre origines multiples (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/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. Pour plus d’informations, consultez [What is CORS?](https://aws.amazon.com/what-is/cross-origin-resource-sharing/)
## Activation ou non de 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`)
Si vous ne parvenez pas à accéder à votre API et que vous recevez un message d'erreur contenant `Cross-Origin Request Blocked`, vous devrez peut-être activer CORS.
Les demandes HTTP cross-origin peuvent être réparties en deux types : les demandes *simples* et les demandes *non simples*.
## Activation de CORS pour une demande simple
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](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests).
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: '*'` ou `Access-Control-Allow-Origin:{{'origin'}}`.
Toutes les autres demandes HTTP cross-origin sont des demandes *non simples*.
## Activation de CORS pour une demande non simple
Si les ressources de votre API reçoivent des demandes non simples, vous devez activer une prise en charge de CORS supplémentaire en fonction de votre type d’intégration.
### Activation de CORS pour les intégrations autres que de proxy
Pour de telles intégrations, le [protocole CORS](https://fetch.spec.whatwg.org/#http-cors-protocol) 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. Vous devez configurer votre API pour envoyer une réponse appropriée à la demande en amont.
Pour créer une réponse en amont :
1. Créez une méthode `OPTIONS` avec une intégration simulée.
1. 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`
1. Définissez le comportement de transfert direct sur `NEVER`. Dans ce cas, la demande de méthode d’un type de contenu non mappé sera rejetée en renvoyant une réponse HTTP 415 Type de support non pris en charge. Pour de plus amples informations, veuillez consulter [Comportement des demandes de méthode pour les charges utiles sans modèles de mappage pour REST APIs dans API Gateway](integration-passthrough-behaviors.md).
1. 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: 'DELETE,GET,HEAD,OPTIONS,PUT,POST,PATCH'`
+ `Access-Control-Allow-Origin: '*'`
Après avoir créé la demande en amont, vous devez renvoyer l’en-tête `Access-Control-Allow-Origin: '*'` ou `Access-Control-Allow-Origin:{{'origin'}}` pour toutes les méthodes compatibles CORS pour toutes les 200 réponses, au moins.
### Activation de CORS pour les intégrations sans proxy à l'aide du AWS Management Console
Vous pouvez utiliser le AWS Management Console pour activer CORS. API Gateway crée une méthode `OPTIONS` et ajoute 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 pour renvoyer l’en-tête `Access-Control-Allow-Origin` pour toutes les méthodes compatibles CORS pour toutes 200 réponses, au moins.
Si les types de médias binaires sont définis sur `*/*` pour votre API, lorsqu’API Gateway crée une méthode `OPTIONS`, remplacez `contentHandling` par `CONVERT_TO_TEXT`.
La commande [update-integration](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-integration.html) suivante modifie le paramètre `contentHandling` en `CONVERT_TO_TEXT` pour une demande d’intégration :
```
aws apigateway update-integration \
--rest-api-id {{abc123}} \
--resource-id {{aaa111}} \
--http-method OPTIONS \
--patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT'
```
La [update-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-integration-response.html)commande suivante change la valeur `contentHandling` en `CONVERT_TO_TEXT` pour une réponse d'intégration :
```
aws apigateway update-integration-response \
--rest-api-id {{abc123}} \
--resource-id {{aaa111}} \
--http-method OPTIONS \
--status-code 200 \
--patch-operations op='replace',path='/contentHandling',value='CONVERT_TO_TEXT'
```
## Activation de la prise en charge de CORS pour les intégrations de proxy
Pour une intégration de proxy Lambda ou de proxy HTTP, votre backend est chargé de renvoyer les en-têtes `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods` 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 ]
```
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!')
}
```
------
**Topics**
+ [Activation ou non de la prise en charge de CORS](#apigateway-cors-request-types)
+ [Activation de CORS pour une demande simple](#apigateway-cors-simple-request)
+ [Activation de CORS pour une demande non simple](#apigateway-enable-cors-non-simple)
+ [Activation de la prise en charge de CORS pour les intégrations de proxy](#apigateway-enable-cors-proxy)
+ [Activation de CORS sur une ressource à l’aide de la console API Gateway](how-to-cors-console.md)
+ [Activation de CORS sur une ressource à l’aide de l’API d’importation API Gateway](enable-cors-for-resource-using-swagger-importer-tool.md)
+ [Test de CORS pour une API API Gateway](apigateway-test-cors.md)