¿Qué es el CORS?

En el pasado, cuando las tecnologías de Internet aún eran nuevas, se producían problemas de falsificación de solicitudes entre sitios (CSRF). Estos problemas enviaban solicitudes de cliente falsas desde el navegador de la víctima a otra aplicación.

Por ejemplo, la víctima iniciaba sesión en la aplicación de su banco. Después, le engañaban para que cargara un sitio web externo en una nueva pestaña del navegador. A continuación, el sitio web externo utilizaba las credenciales de las cookies de la víctima y retransmitía los datos a la aplicación bancaria mientras se hacía pasar por esta. De este modo, usuarios no autorizados accedían de manera no deseada a la aplicación bancaria.

En la actualidad, para evitar estos ataques de CSRF, todos los navegadores implementan la política del mismo origen.

Política del mismo origen

Hoy en día, los navegadores exigen que los clientes solo puedan enviar solicitudes a un recurso con el mismo origen que la URL del cliente. El protocolo, el puerto y el nombre de host de la URL del cliente deben coincidir con el servidor que solicita.

Por ejemplo, considere la comparación del origen de las siguientes URL con la URL del cliente http://store.aws.com/dir/page.html.

URL	Resultado	Motivo
http://store.aws.com/dir2/new.html	Mismo origen	Solo la ruta es diferente
http://store.aws.com/dir/inner/other.html	Mismo origen	Solo la ruta es diferente
https://store.aws.com/page.html	Origen diferente	Protocolo diferente
http://store.aws.com:81/dir/page.html	Origen diferente	Puerto diferente (http:// es el puerto 80 por defecto)
http://news.aws.com/dir/page.html	Origen diferente	Host diferente

Por lo tanto, la política del mismo origen es altamente segura, pero es inflexible para los casos de uso auténticos.

El uso compartido de recursos entre orígenes (CORS) es una ampliación de la política del mismo origen. Lo necesita para compartir recursos autorizados con terceros externos. Por ejemplo, necesita CORS cuando quiera extraer datos de API externas que sean públicas o autorizadas. También necesita CORS si quiere permitir el acceso autorizado de terceros a los recursos de su propio servidor.

En HTTP, los métodos de solicitud son las operaciones de datos que el cliente desea que realice el servidor. Los métodos HTTP más comunes son GET, POST, PUT y DELETE.

En una interacción habitual de uso compartido de recursos entre orígenes (CORS), el navegador envía los encabezados de solicitud y de control de acceso al mismo tiempo. Por lo general, se trata de solicitudes de datos GET y se consideran de bajo riesgo.

Sin embargo, algunas solicitudes HTTP se consideran complejas y requieren la confirmación del servidor antes de enviar la solicitud real. El proceso de aprobación previa se denomina solicitud preparatoria.

Solicitudes entre orígenes complejas

Las solicitudes entre orígenes son complejas si utilizan alguna de las siguientes opciones:

• Métodos que no sean GET, POST o HEAD
• Encabezados que no sean Accept-Language, Accept o Content-Language
• Encabezados Content-Type que no sean multipart/form-data, application/x-www-form-urlencoded o text/plain

Así, por ejemplo, las solicitudes para eliminar o modificar datos existentes se consideran complejas.

¿Cómo funcionan las solicitudes preparatorias?

Los navegadores crean solicitudes preparatorias si son necesarias. Es una solicitud OPTIONS como la siguiente.

OPTIONS/data HTTP/1.1 Origen: https://ejemplo.com Access-Control-Request-Method: DELETE

El navegador envía la solicitud preparatoria antes del mensaje de solicitud real. El servidor debe responder a la solicitud preparatoria con información sobre las solicitudes entre orígenes que el servidor está dispuesto a aceptar desde la URL del cliente. Los encabezados de respuesta del servidor deben incluir lo siguiente:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

A continuación se muestra un ejemplo de respuesta del servidor.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://noticias.ejemplo.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

La respuesta de verificación previa a veces incluye un encabezado adicional Access-Control-Max-Age. Esta métrica especifica la duración (en segundos) para que el navegador almacene en caché los resultados de la verificación previa en el navegador. El almacenamiento en caché permite al navegador enviar varias solicitudes complejas entre las solicitudes de verificación previa. No tiene que enviar otra solicitud de verificación previa hasta que transcurra el tiempo especificado por max-age.

 

Debe tener en cuenta lo siguiente cuando configure la opción de compartir recursos entre orígenes (CORS) en su servidor.

Definición de listas de acceso adecuadas

Siempre es mejor conceder acceso a dominios individuales utilizando listas separadas por comas. Hay que evitar el uso de caracteres comodín a menos que se quiera hacer pública la API. De lo contrario, el uso de caracteres comodín y expresiones comunes puede crear vulnerabilidades.

Por ejemplo, supongamos que escribe una expresión común que concede acceso a todos los sitios con el sufijo sitioweb-permitido.com. Con una expresión, está concediendo acceso a api.sitioweb-permitido.com y news.sitioweb-permitido.com. Pero también está concediendo inadvertidamente acceso a sitios no autorizados que pueden utilizar dominios como sitioweb-contenidomalintencionadopermitido.com.

Evite utilizar un origen null en su lista

Algunos navegadores envían el valor null en la cabecera de la petición en determinados casos, como en las peticiones de archivos o las peticiones desde el host local.

Sin embargo, no debe incluir el valor null en su lista de acceso. También implica riesgos de seguridad, ya que las solicitudes no autorizadas que contengan cabeceras con valor null pueden obtener acceso.