CORS como configurarlo sin cargarte la seguridad

En antaño, donde la web era completamente renderizada desde el backend, este era un problema poco habitual. Posiblemente como yo, te llegaste a topar con este error mientras felizmente desarrollabas una de tus primeras SPA en Vue o React e intentabas solicitar información del servidor de tu aplicación.

¡Que problema! Bueno, descarguemos una librería o pongamos un bonito header y pum, solucionado.

¡Hey! Cuidado, seguro sabrás que las soluciones rápidas no siempre son las óptimas.

En este post te explicaré la importancia de esas 4 letras y como resolver el problema que surge de ellas sin dejar un hueco en la seguridad. Pero antes de eso es necesario conocer el concepto que le da origen.

Same-origin policy

La política o regla de same-origin, es una implementación existente en los navegadores que evita, a las aplicaciones web, interactuar con dominios diferentes al suyo. Para esto se toma en cuenta que tanto el protocolo, el host y el puerto sean idénticos en origen y destino.

Ejemplo de esto, es hacer una llamada desde http://store.company.com hacia http://news.company.com. En este caso los hosts difieren y la política de same-origin rechaza continuar con el proceso.

Su existencia es por razones de seguridad. Pongamos un escenario en el que inicias sesión en un sitio que, desafortunadamente aún tiene huecos de seguridad. La sesión será guardada en una cookie dentro de tu navegador. Más adelante, continúas explorando sin haber cerrado la sesión en el sitio inicial. Atraído por una imagen con excesivo clickbait ingresas a otra página, ¡Ups! tu no te das cuenta pero tiene código malicioso, y a través de XSS obtiene los datos de tu sesión. La nueva página intenta ahora hacer operaciones a través de los puntos de acceso de la página inicial y… falla rotundamente. Same-origin policy al rescate.

CORS

Entendiendo ya la política de same-origin podemos decir que CORS (Cross-origin resource sharing) es la forma de evitar que se bloqueen peticiones legítimas de sitios diferentes.

Si ya has tenido este problema antes, seguro sabrás que basta con añadir un texto en los headers del backend para resolverlo (o agregar una librería que justo haga esto por ti).

Solución rápida

Access-Control-Allow-Origin: *

Añadir este encabezado en la respuesta de las peticiones que se hagan a tu backend, solucionará el problema, haciendo que cualquier sitio tenga acceso al recurso en cuestión.

¿Que hay de la seguridad? Bien, pues mientras el recurso expuesto por esta cabecera no sea información sensible, es una solución válida.

Solución óptima

Access-Control-Allow-Origin: <origin>

En la mayoría de los casos no querrás exponer tus recursos a cualquier página, por lo que deberás considerar especificar el sitio al que le darás acceso.

Para esto basta con añadir el mismo header, pero ahora con los 3 datos que same-origin verifica: protocolo, host y puerto.

Access-Control-Allow-Origin: http://localhost:3000

¿Cómo permitir el acceso a mas de un sitio web?

El header de Allow-origin solo permite asignar un solo sitio a la vez. Sin embargo, esto no significa que no puedas tener una white-list de sitios permitidos. Para esto es necesario un poco mas de configuración, como hacer al header dinámico acorde al origen que reciba.

Más headers

Si bien, Allow-origin es el que directamente te ayudará con los problemas de same-origin, no es el único. De hecho, hay muchas formas de configurar CORS. Si tienes interés en ellos puedes encontrar aquí la lista completa de headers.

Ahora dime ¿ya te habías topado con este error antes? ¿Al igual que yo tomaste la solución rápida para resolverlo? Pon tus respuestas en los comentarios.

Deja un comentario

Blog de WordPress.com.

Subir ↑