Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es CORS?



Las API son redes complejas de aplicaciones, interfaces, frontends y backends interconectados. No siempre es fácil dar sentido a estos sistemas. Cuando muchos de los datos que ingresan a un sistema provienen de fuentes externas que van desde confiables a no confiables, conocidos a desconocidos, la forma más fácil de clasificar esos datos es clasificarlos por el origen de la fuente, es decir, no hablar de ellos. la naturaleza de los datos, sino más bien la naturaleza de aquello que envió los datos.

Por esta razón, gran parte del espacio API se rige por la idea del origen y las diversas restricciones sobre dicho sistema. Definir qué es el origen cruzado, qué es el mismo origen y cómo interactúan esos sistemas es un tema complejo que lo es aún más debido a la naturaleza de la confianza implícita entre los orígenes. Hoy, veremos un sistema que intenta resolver muchos de los problemas que surgen al admitir tipos de datos de origen múltiple: el intercambio de recursos de origen cruzado .

¿Qué es "Origen"?

Cuando se habla de interacciones API en el contexto de CORS, es útil comprender qué es un "origen". Las API se preocupan tanto por la solicitud en sí como por el origen de la solicitud. La fuente de la solicitud se considera el "origen", y tanto la relación de la fuente en términos del recurso HTTP como el modo en que se realizó la solicitud pueden crear problemas con las restricciones de origen.

De forma predeterminada, los sistemas API normalmente se ejecutan con una política del mismo origen, es decir, las solicitudes se generan internamente y luego se responden con datos de una tienda interna (siempre que compartan el origen indicado con el recurso en cuestión). Por ejemplo, si una solicitud proviene de example.com/api"example.com/api", entonces este es el mismo origen y, como tal, es de confianza implícita.

El problema viene con el hecho de que una variedad de solicitudes de origen cruzado pueden ser normales y válidas. Por ejemplo, una solicitud que proviene de un dominio diferente puede ser absolutamente legítima, especialmente si las solicitudes provienen de dominios separados por la lógica empresarial. Por ejemplo, una solicitud de puede ser completamente válida y, en este caso, aunque los dos dominios son diferentes, pertenecen al mismo proveedor. Otros casos de uso, como los subdominios ( ), las diferencias de puerto ( ) y las diferencias de protocolo ( ), pueden restringirse debido a políticas del mismo origen, incluso si las solicitudes son normales, legítimas y sensibles.examplecorporate.com/apiexampleretail.com/apiexample.comresources.example.comexample.com:80example.com:10777https://example.comhttp://example.com

En muchos casos, los datos deben separarse debido a una lógica empresarial simple. Por ejemplo, si tenemos dos API, es posible que necesitemos extraer de ambas para enviar un artículo de noticias a publish.example.comAunque todos están en el mismo sitio, y aunque (en teoría) comparten una red confiable, son orígenes técnicamente diferentes.images.example.comcontent.example.compublicar ejemplo com . Aunque todos están en el mismo sitio, y aunque (en teoría) comparten una red confiable, son orígenes técnicamente diferentes.

¿Qué es CORS?

CORS está diseñado para admitir todos estos casos de uso y, al mismo tiempo, permite opciones de seguridad sólidas. CORS es un estándar de W3C que sirve como término medio; en esencia, permite que un recurso permita algunas solicitudes de origen cruzado mientras rechaza otras. Esto es más seguro y más flexible que otras soluciones que se han intentado debido al hecho de que es inclusivo: todo lo que se incluye como parte de la asignación de origen cruzado se establece y se entiende explícitamente.

Esta es parte de la razón por la que CORS a menudo se considera un impulso a la seguridad. Otras opciones de origen cruzado intentan ofuscar el origen real de la solicitud; CORS, en comparación, simplemente permite que esa solicitud continúe a través de la transformación y la inclusión, lo que proporciona un mayor nivel de granularidad sin la intromisión de otras opciones. En un mundo de "todo o nada", CORS ofrece opciones.

¿Cómo funciona CORS?

CORS hace lo que hace mediante la inclusión de encabezados especiales. Un servidor configurado correctamente proporcionará estos encabezados a los navegadores, que luego analizarán la solicitud o harán que falle. Hay una gran cantidad de encabezados dentro del estándar CORS, pero el encabezado de habilitación principal es el encabezado Access-Control-Allow-Origin, que especifica qué orígenes pueden acceder a qué recursos.

Básicamente, existen dos tipos de solicitudes CORS. Las peticiones sencillas son las que utilizan ya sea el GET, verbos POST, o cabeza, un CORS se utiliza cabecera de fallos en la lista, no hay objeto ReadableStream o eventos Los detectores están involucrados, y, o bien application/x-www-form-urlencodedtext/plainomultipart/form-data<c/ode> are used as the Content-Type header. Assuming all of these criteria are met, the request is considered “simple”.

Un tipo de solicitud más complejo se conoce como verificación previa. Este es un término que puede encontrar explícitamente declarado cuando se muestran las herramientas de CORS, ya que su inclusión significa que se permiten algunas cosas muy específicas que no están permitidas en una solicitud simple. Una solicitud de verificación previa envía primero una solicitud HTTP utilizando el verbo OPTIONS para averiguar si la solicitud es segura y aceptada. El resultado de esta llamada determina cuál es la interacción CORS y la respuesta del protocolo. Lo hace configurando el método de la solicitud (usando Access-Control-Request Method), los encabezados personalizados (usando Access-Control-Request-Headers) y el origen de la llamada.

Ejemplo practico

Veamos un ejemplo práctico de dónde podría tener sentido CORS. Podemos imaginar un escenario en el que tengamos un servicio de video en streaming que brinde contenido bajo demanda a los usuarios. Para cumplir con nuestras obligaciones de contenido y ofrecer una oferta sólida a nuestros usuarios, tenemos servidores que proporcionan diferentes tipos de contenido según lo que el usuario haya marcado en su configuración. Esto ahorra ancho de banda, aumenta la velocidad del flujo de provisión de servicios de contenido y mejora su experiencia de usuario.

Para aprovechar estos beneficios, tenemos nuestro contenido organizado a través de cuatro API:

media.example.com
closedcaptions.example.com
accounts.example.com
content.example.com

Debido a que todas nuestras API tienen dominios diferentes, las consideraríamos de origen cruzado. Necesitaríamos configurar cada una de estas API para aceptar solicitudes de origen cruzado de las demás, lo que puede ser bastante complicado; lo que podemos hacer aquí es aprovechar nuestras API y el sistema CORS para manipular los encabezados sin problemas.

Primero, cuando una solicitud ingresa a nuestra API, haremos que la verificación de la API tome el contenido del encabezado y lo pase internamente. Desde aquí, podemos comparar el valor del encabezado con una "lista blanca" para ver si coincide con alguno de nuestros dominios internos. Si lo hace, podemos pasarlo al sistema CORS usando la respuesta del encabezado Access-Control-Allow-Origin.

Aquí puede ver cuán poderoso es CORS: con una lógica comparativamente simple, ¡podemos manejar incluso una situación compleja de múltiples API como esta!

Consideraciones CORS

Como cualquier herramienta, CORS tiene varios elementos que la hacen extremadamente peligrosa cuando se usa incorrectamente. Estas áreas de preocupación deben tenerse en cuenta al configurar un entorno CORS; si bien esta lista no es exhaustiva de tales preocupaciones, sí representa las configuraciones erróneas más comunes, las suposiciones incorrectas y los errores desafortunados que se observan en la naturaleza.

Permitir todos los comodines

Quizás el error más común es simplemente establecer la variable Access-Control-Allow-Origin en un comodín, "*". Lo que hace es permitir todas las solicitudes, independientemente de su origen. Como se discutió anteriormente, CORS está destinado a ser un término medio entre la ausencia de restricciones de origen cruzado y un sistema completamente bloqueado; en consecuencia, el uso del comodín, en este caso, es básicamente el extremo del espectro sin restricciones de origen cruzado en todas.

¿Qué tan segura sería una caja fuerte si cualquier cerradura pudiera girar los vasos? ¿Qué utilidad tendría una tarjeta de identificación si alguien pudiera imprimir una? CORS es una herramienta poderosa para asegurar las cosas de manera granular: si simplemente va a permitir todo, entonces realmente no está usando CORS, está despojando a CORS de sus poderes.

Hay uno o dos casos de uso en los que esto podría ser apropiado, por ejemplo, una API abierta que se vincule con sitios de terceros y sea completamente independiente de la intención, pero estos son la excepción y no la norma.

Uso de encabezados híbridos y no estándar

Uno de los errores más comunes que se cometen al usar CORS es un malentendido básico del sistema de encabezado y cómo los clientes interactúan con él. CORS no permite múltiples dominios en el encabezado Access-Control-Allow-Origin, ni permite dominios comodín como , ninguno de estos son usos correctos del sistema, incluso si parece que deberían funcionar.example.com

Además, omitir los protocolos también puede crear problemas. CORS requiere que establezca el protocolo en cuestión; el uso solo funcionará si ya está trabajando en el puerto 80. De manera similar, si intenta establecer un puerto o protocolo no estándar, como en lugar de , la configuración de CORS fallará.http://localhostexample.comhttps://example.com

Conclusión

CORS es en realidad un sistema bastante simple una vez que comprendes tanto su necesidad como el sistema subyacente que lo impulsa. La implementación de CORS puede resultar en una seguridad más granular, sí, pero también puede abrir nuevas e importantes vías para la interacción y transmisión de datos. Correctamente configurado y creado dentro de una arquitectura API planificada, CORS es una herramienta maravillosa.

¿Qué opinas de CORS? CORS a veces se configura con un comodín para permitir todo. ¿Cree que nuestras sugerencias en contra de esto son demasiado estrictas? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios