CORS es una función de seguridad implementada por los navegadores que controla cómo las páginas web de un dominio pueden solicitar e interactuar con los recursos de otro dominio. Ayuda a prevenir el acceso no autorizado de origen cruzado al tiempo que permite el intercambio legítimo de datos de origen cruzado. CORS utiliza encabezados HTTP para establecer un diálogo entre los navegadores y los servidores, determinando si se deben permitir las solicitudes de origen cruzado en función del origen y otros factores.
El intercambio de recursos entre orígenes (CORS, del inglés Cross-Origin Resource Sharing) es la excepción controlada a la política del mismo origen. Permite que un servidor decida compartir sus respuestas con scripts de otros orígenes devolviendo cabeceras HTTP específicas. En las peticiones simples, el navegador envía una cabecera Origin y comprueba el Access-Control-Allow-Origin de la respuesta antes de dejar que el script que llama lea el cuerpo. Para métodos o cabeceras que podrían cambiar el estado, el navegador primero envía una petición de preverificación OPTIONS, y el servidor debe aprobar el método, las cabeceras y el origen. Cuando intervienen credenciales como las cookies, el servidor debe establecer Access-Control-Allow-Credentials: true y devolver un origen concreto en lugar de un comodín. El navegador hace cumplir todo esto.
CORS suele relajarse hasta que las peticiones dejan de fallar, lo que desmantela en silencio las protecciones del mismo origen que rodean a los endpoints sensibles. Reflejar la cabecera Origin de la petición dentro de Access-Control-Allow-Origin y permitir además credenciales deja, en la práctica, que cualquier sitio lea respuestas autenticadas en nombre de una víctima con sesión iniciada, exponiendo datos de la cuenta o tokens. Confiar en un comodín, en una expresión regular demasiado amplia que coincida con subdominios controlados por el atacante, o en el origen literal null son errores frecuentes. Como el fallo es invisible en el uso normal y solo aparece cuando se abusa de él, un CORS permisivo en una API es un vector real de exposición de datos, no un ajuste cosmético.
Mantén una lista de permitidos explícita de orígenes de confianza y compara el Origin entrante con ella de forma exacta en lugar de reflejar lo que llegue. Nunca combines un comodín con peticiones que manejan credenciales, evita permitir el origen null y limita las reglas permisivas al conjunto más reducido de rutas y métodos que de verdad lo necesiten. Mantén el almacenamiento en caché de la preverificación (Access-Control-Max-Age) en un valor razonable y vuelve a revisar las políticas cuando aparezcan nuevos subdominios. CORS es un mecanismo neutral de la plataforma web, así que la defensa principal es una configuración correcta del servidor y su revisión; una capa de monitoreo del lado del cliente lo complementa al vigilar cómo se comportan los scripts de terceros, pero CORS en sí depende de los endpoints que tú controlas.
No directamente. CORS lo aplica el navegador y regula si un script puede leer una respuesta de otro origen; no impide que clientes que no son navegadores, como curl o un proxy del lado del servidor, lean tu API. Protege a los usuarios de que otros sitios lean sus respuestas autenticadas, no al servidor de ser invocado.
El navegador envía una preverificación para las peticiones que no son simples, por ejemplo las que usan PUT o DELETE, cabeceras personalizadas o ciertos tipos de contenido. Pregunta al servidor, mediante cabeceras, si el método, las cabeceras y el origen reales están permitidos antes de enviar la petición real, evitando así llamadas inesperadas que cambien el estado.
We answer client-side security questions every day. Bring yours.