CORS
Y como sobrevivir a él …
Comúnmente los sitios web’s se encontrarán conformados por dos elementos: el Frontend y el Backend. Estos dos componentes tradicionalmente se encuentran en el mismo servidor, por lo que las peticiones del Frontend hacia el Backend, para obtener los datos para ser mostrados al usuario, siguen la política conocida como “del mismo origen”.
Sin embargo, a principios de los 2000’s no era posible acceder a los datos almacenados en un servidor distinto, debido a los riesgos de seguridad que la practica traía consigo. Se considera, que dos páginas o sitios tienen un origen distinto, si el protocolo, puerto o dominio difiere entre ellos.
La medida de protección que se implemento en los navegadores web para intercambiar información de forma segura entre sitios con orígenes distintos, que llamaremos como sitios A y B, se basó en que el sitio A expresara de forma explícita que B tenía autorizado el acceso a sus datos.
Esta autorización se verificaría en el sitio B, de tal forma que de no estar autorizado el navegador web bloquearía al usuario el acceso a los datos pedidos al sitio A.
La forma en que esta verificación ser realiza es gracias a las cabeceras HTTP, el sitio B enviará al sitio A una cabecera predeterminada llamada Origin, la cual contendrá el protocolo (http/https), el nombre de dominio (sitioB.com) y el puerto (80 como predeterminado) utilizados. El sitio A deberá responder con una cabecera llamada Access-Control-Allow-Origin, en la cual indicará el origen que tiene permitido acceder al recurso (solo se puede indicar un origen).
El navegador web realizara internamente la verificación de que el valor de la cabecera Origin sea la misma que la contenida en la cabecera Access-Control-Allow-Origin, de ser iguales el navegador mostrara los datos al usuario; pero de no ser asi, el navegador retornara el evento error de XMLHttpRequest y bloqueara el acceso a los datos.
La cabecera Access-Control-Allow-Origin, puede contener 3 valores posibles:
Access-Control-Allow-Origin: <origen>
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: null
El origen autorizado, el comodín “*” el cual permite a cualquier origen el acceso de los datos solicitados, pero solo si la petición se realiza sin credenciales; en caso contrario se procesará como error y el valor null el cual es el valor predeterminado y niega el acceso a todos los sitios.
Este proceso descrito es al que se le conoce como Solicitud CORS simple. Sin embargo, para solitudes HTTP que modifican datos en el servidor, la especificación establece que se emplee una Solicitud CORS no simple o también conocida como Solicitud verificada. La solicitud verificada retoma el proceso que realiza en la Solicitud simple, pero agrega un paso previo.
El sitio B enviará los métodos HTTP a los que este desea acceder del servidor además del nombre de las cabeceras HTTP que el servidor leerá por parte del sitioB y por supuesto el origen desde el que se está haciendo la petición.
Las cabeceras con esta información se enviaran con un método de solicitud HTTP OPTIONS, el servidor responderá con cabeceras HTTP que indican los métodos HTTP accesibles, las cabeceras consideradas validas y el sitio que puede acceder a este recurso, el navegador comprobara que estos datos recibidos coincidan con los datos enviados y si es asi, al contar con la “aprobación” del servidor, se enviara la verdadera solicitud con el método de solicitud HTTP verdadero, empleando una Solicitud CORS simple.
De esta forma, si el sitioB desea realizar una petición POST al sitioA, y dentro de la petición POST también adjuntar información en las cabeceras HTTP Authorization y Content-Type para que el sitioA acceda a estos datos al momento de procesar la solicitud POST, el proceso de la primera fase de la Solicitud verificada será la siguiente:
Es posible indicar mediante la cabecera Access-Control-Max-Age, el número de segundos que la primera fase de la solicitud verificada es vigente, de tal forma que en próximas solicitudes CORS solo se emplee la Solicitud simple y de esta forma evitar que el servidor se sobrecargue de solicitudes HTTP.
Por la tanto el proceso completo de una Solicitud verificada se vería de esta forma:
Si has notado algún error en este artículo o sientes que se puedes hacer mejoras, por favor házmelo saber en la sección de comentarios, ¡lo aprecio mucho!
Finalmente, si ha disfrutado este artículo y siente que ha aprendido algo valioso, por favor comparta para que otros también puedan aprender de él.
¡Gracias por leer!
Referencias:
