Uno de los primeros conceptos con los que tendremos que lidiar a la hora de desarrollar aplicaciones de internet enriquecidas (RIA) es el concepto de Cross-origin resource sharing (CORS).
La finalidad de este protocolo ideado a principios de 2004 es la de permitir el acceso a recursos alojados en un dominio en particular a través de peticiones desde cualquier otro dominio diferente.
Muy bien, pero ¿cuáles son las implicaciones reales?, pues empezaremos desde el principio..
ORIGENES DEL CORS
Antes de la existencia del protocolo CORS, si queriamos, por ejemplo, hacer una petición AJAX a una URL determinada, los navegadores de la época (IE < 8.0, Firefox < 3.5, Chrome < 3) solo te iban a permitir realizar esa petición a URLs del mismo dominio.
Es decir, si la página cargada se encuentra en el dominio www.midominio.es, sólo se podía acceder a recursos del tipo www.midominio.es/recurso.
No solo eso, sino que también eran rechazadas peticiones al mismo dominio pero con:
- Diferente protocolo (ftp://www.midominio.es)
- Diferente puerto (www.midominio.es:1234)
Hasta la aparición del CORS, existía alguna manera de pseudo evadir estas limitaciones, como puede ser el uso de JSONP, pero no llegaban a ser soluciones estandarizadas ni genéricas que se pudiesen aplicar en todas las situaciones.
DEFINIENDO UNA POLÍTICA CORS
Sin embargo ahora, podemos establecer una política CORS para gestionar estas situaciones. La pregunta es, ¿cómo hacemos eso?
Pues de la siguiente manera:
Los navegadores actuales cuando detectan una posible petición CORS, lo primero que hacen es dejar esta petición en espera y lanzar una petición http propia con el método OPTIONS. A primera vista puede parecer desconcertante, ya que el navegador gestiona la petición por su cuenta y si no estás familiarizado con este protocolo lo más normal es que te pierdas en el flujo, pero una vez entendido es bastante simple.
Como decíamos, lo primero que recibirá el servidor es una petición del tipo OPTIONS. Si esta petición no está gestionada, el navegador bloqueará la petición actual y finalizará la ejecución, tal y como ocurría anteriormente.
Para permitir el acceso cross domain, es necesario capturar esa petición OPTIONS en el servidor, tal y como se haría con cualquier otra petición http, y devolver una respuesta con la siguiente cabecera:
Access-Control-Allow-Origin: http://www.midominio.es
Con esta cabecera estamos permitiendo el acceso a cualquier petición que venga del dominio www.midominio.es. El navegador validará esta respuesta, y si efectivamente, la petición se ha hecho desde ese dominio, dejará paso ya a la petición http original, habilitando de esa forma el acceso interactivo a recursos desde diferentes dominios.
En caso de querer permitir acceso a todas las peticiones vengan del dominio que vengan, la cabecera que se devuelva deberá ser del tipo:
Access-Control-Allow-Origin: *
PROBLEMAS DE SEGURIDAD
Pero todo este potencial que nos ofrece el protocolo CORS viene con un riesgo oculto. Y es que no podemos empezar a permitir el acceso indiscriminado a nuestros recursos desde dominios externos ya que podríamos estar generando agujeros de seguridad enormes.
Así que es necesario determinar con cuidado cuales son los dominios a los que damos acceso, y por lo general, el permitir el acceso a todos los dominios (‘*’), suele ser una práctica muy desaconsejada.
¿Listos para utilizar el CORS en vuestras aplicaciones?
