CORS para las API de REST en API Gateway
Intercambio de Recursos de Origen Cruzado (CORS)
Determinar si se habilita la compatibilidad con CORS
Una solicitud HTTP de origen cruzado es una que se hace para:
-
Un dominio diferente (por ejemplo, de
example.com
aamazondomains.com
) -
Un subdominio diferente (por ejemplo, de
example.com
apetstore.example.com
) -
Un puerto diferente (por ejemplo, de
example.com
aexample.com:10777
) -
Un protocolo diferente (por ejemplo, de
https://example.com
ahttp://example.com
)
Si no puede acceder a la API y recibe un mensaje de error que contiene Cross-Origin Request Blocked
, es posible que deba habilitar CORS.
Las solicitudes HTTP de origen cruzado se pueden dividir en dos tipos: solicitudes simples y solicitudes no simples.
Habilitar CORS para una solicitud sencilla
Una solicitud HTTP es simple si se cumplen todas las condiciones siguientes:
-
Se emite contra un recurso de API que permite únicamente solicitudes
GET
,HEAD
yPOST
. -
Si se trata de una solicitud de método
POST
, debe incluir un encabezadoOrigin
. -
El tipo de contenido de la carga de la solicitud es
text/plain
,multipart/form-data
oapplication/x-www-form-urlencoded
. -
La solicitud no contiene encabezados personalizados.
-
Cualquier requisito adicional enumerado en la documentación de CORS de Mozilla para solicitudes simples
.
Para solicitudes simples de método POST
de origen cruzado, la respuesta del recurso debe incluir el encabezado Access-Control-Allow-Origin: '*'
o Access-Control-Allow-Origin:
.'origin'
Todas los demás solicitudes HTTP de origen cruzado son solicitudes no simples.
Habilitar CORS para una solicitud no sencilla
Si los recursos de su API reciben solicitudes no sencillas, deberá habilitar la compatibilidad con CORS adicional en función del tipo de integración.
Habilitar CORS para integraciones que no sean de proxy
Para estas integraciones, el protocolo CORS
Para crear una respuesta con comprobación previa:
Cree un método
OPTIONS
con una integración simulada.-
Añada los siguientes encabezados de respuesta a la respuesta del método 200:
-
Access-Control-Allow-Headers
-
Access-Control-Allow-Methods
-
Access-Control-Allow-Origin
-
-
Configuración del comportamiento de acceso directo de integración a
NEVER
. En este caso, la solicitud del método de un tipo de contenido sin asignar se rechazará con una respuesta HTTP 415 Unsupported Media Type. Para obtener más información, consulte Comportamientos del acceso directo a la integración. -
Introduzca valores para los encabezados de las respuestas. Para permitir todos los orígenes, todos los métodos y los encabezados comunes, utilice los siguientes valores de encabezado:
-
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: '*'
-
Tras crear la solicitud con comprobación previa, debe devolver el encabezado Access-Control-Allow-Origin: '*'
o Access-Control-Allow-Origin:
de todos los métodos habilitados para CORS para al menos las 200 respuestas.'origin'
Habilitar CORS para integraciones que no sean de proxy mediante AWS Management Console
Puede utilizar la AWS Management Console para habilitar CORS. API Gateway crea un método OPTIONS
y agrega el encabezado Access-Control-Allow-Origin
a las respuestas de integración de métodos existentes. Esto no siempre funciona y, a veces, es necesario modificar manualmente la respuesta de integración para que devuelva el encabezado Access-Control-Allow-Origin
de todos los métodos compatibles con CORS de al menos las 200 respuestas.
Habilitar la compatibilidad con CORS para integraciones de proxy
En el caso de una integración de proxy Lambda o de proxy HTTP, el backend es responsable de devolver los encabezados Access-Control-Allow-Origin
, Access-Control-Allow-Methods
y Access-Control-Allow-Headers
, ya que una integración de proxy no devuelve una respuesta de integración.
Las siguientes funciones de ejemplo de Lambda devuelven los encabezados CORS necesarios: