¿Por qué mi recuperación falla con un error CORS?

El servidor al que llama no incluía el encabezado Access-Control-Allow-Origin apropiado para su origen. O el servidor debe estar configurado para permitirle, o debe llamarlo desde el mismo origen (normalmente a través de un proxy backend).

¿Puedo omitir CORS como desarrollador?

Desde su propio código en el navegador, no: el navegador lo aplica. Desde su propio servidor (código backend), sí, porque CORS no se aplica a solicitudes de servidor a servidor. La solución común es un proxy de backend: su frontend llama a su backend; su backend llama a la API de terceros.

¿Cors protege mi API?

No directamente. Se puede acceder a la API independientemente de CORS: el navegador aún envía la solicitud. La protección es que JavaScript en otros sitios no puede leer las respuestas. Para proteger realmente la API, utilice autenticación y autorización en el servidor.

¿Debo usar Access-Control-Allow-Origin: *?

Solo para API públicas que no aceptan credenciales. Para cualquier cosa que tenga cookies o encabezados de autorización, utilice orígenes específicos o haga eco del origen de llamada (con validación). Los navegadores no permiten credenciales comodín +.

¿Por qué CORS realiza una verificación previa solo de algunas solicitudes?

Las solicitudes simples (GET, HEAD, POST con tipos de contenido básicos y sin encabezados personalizados) están exentas; son equivalentes a lo que los formularios HTML ya podían hacer antes de que existiera CORS. Las solicitudes complejas no tienen ningún formato HTML análogo, por lo que realizan una verificación previa para darle al servidor la oportunidad de rechazarlas antes de cualquier cambio de estado.

CORS explicado: cómo deciden los navegadores cuándo se permiten solicitudes entre orígenes

CORS es una de las tecnologías web más confusas porque se trata de decirle a los navegadores qué permitir, no de bloquear ataques al servidor. Una vez que entiendes esa distinción, las reglas tienen sentido. CORS permite a los servidores otorgar permisos de origen cruzado de forma selectiva; La política del mismo origen es el no predeterminado.

El cuerpo completo del artículo se proporciona en inglés a continuación.

Uso compartido de recursos entre orígenes (CORS) es un mecanismo de navegador que permite a un servidor declarar qué otros orígenes pueden acceder a sus respuestas. Combinado con la política del mismo origen (la política del mismo origen es "no permitir que un origen lea las respuestas de otro"), CORS proporciona el mecanismo para una relajación selectiva. "Origen" significa esquema + host + puerto; https://a.example.com y https://b.example.com tienen orígenes diferentes.

La política impide que el JavaScript de un sitio lea sus datos en otro sitio en el que haya iniciado sesión. Sin ella, cada sitio que visite podría leer su Gmail, su banco, sus repositorios privados; su navegador envía sus cookies automáticamente, por lo que el destino responderá felizmente y el JS del atacante vería la respuesta.

Qué agrega CORS

Muchos casos de uso legítimos requieren lecturas de orígenes cruzados: fuentes de una CDN, llamadas API desde un frontend a un backend en un dominio diferente, widgets de redes sociales integrados. CORS permite que el servidor que responde diga explícitamente "sí, este otro origen puede leer mis respuestas".

El servidor incluye el encabezado Access-Control-Allow-Origin en su respuesta. El navegador comprueba: si el origen de la solicitud coincide con el valor (o es el comodín *), la respuesta se expone a JavaScript. De lo contrario, el navegador impide que JavaScript lo lea. La solicitud todavía fue , el servidor todavía la recibió y procesó ; solo la visibilidad de JavaScript está restringida.

Solicitudes simples frente a solicitudes verificadas previamente

Para solicitudes "simples" (GET, HEAD, POST con tipos de contenido básico), el navegador envía la solicitud y verifica CORS en la respuesta. Si CORS no lo permite, JavaScript no puede leerlo.

Para solicitudes "complejas" (PUT, DELETE, encabezados personalizados, tipo de contenido JSON), el navegador primero envía una solicitud preflight OPTIONS preguntando "¿puede el origen X hacerle esta solicitud?" El servidor responde con métodos y encabezados permitidos. Solo si se aprueba, el navegador envía la solicitud real.

// Verificación previa
OPCIONES /api/usuarios HTTP/1.1
Origen: https://app.example.com
Método de solicitud de control de acceso: ELIMINAR
Encabezados-de-solicitud-de-control-de-acceso: Autorización

// respuesta del servidor
HTTP/1.1 204 Sin contenido
Control-de-acceso-permitir-origen: https://app.example.com
Métodos de permiso de control de acceso: BORRAR, OBTENER, PUBLICAR
Access-Control-Allow-Headers: Autorización, Tipo de contenido
Access-Control-Max-Age: 86400

La verificación previa evita que los navegadores envíen solicitudes complejas de cambio de estado a servidores que no las esperan, una defensa básica incluso contra servidores mal configurados.

Credenciales y CORS

Las cookies y los encabezados de autenticación HTTP ("credenciales") no se envían solicitudes de origen cruzado de forma predeterminada. Para incluirlos, JavaScript debe solicitar:

fetch('https://api.example.com/data', { credentials: 'include' })

Y el servidor debe responder con Access-Control-Allow-Credentials: true y un origen específico (no comodín *) en Acceso-Control-Permitir-Origen. Este es el problema común: Access-Control-Allow-Origin: * + credenciales = nada funciona.

Malentendidos comunes de CORS

CORS no es una característica de seguridad para servidores. La solicitud llega al servidor independientemente de CORS. El navegador bloquea JavaScript de reading la respuesta. Los servidores aún deben autenticarse y autorizarse.
CORS no se aplica a todas las solicitudes. Las solicitudes del mismo origen no activan CORS. Las solicitudes de servidor a servidor tampoco. El origen cruzado del navegador al servidor es el único lugar donde reside CORS.
El comodín * es peligroso cuando se combina con cookies. Muchos tutoriales sugieren Access-Control-Allow-Origin: * como solución rápida. Para API públicas sin credenciales, está bien. Para cualquier cosa con autenticación, los errores rotos.
CORS son problemas del lado del servidor. Cuando ve errores de CORS en la consola del navegador, la solución está en el servidor que responde, no en el código de solicitud.

CORS vs CSRF

Se confunde fácilmente. CORS controla lo que el navegador expone a JavaScript. CSRF (consulte nuestro artículo CSRF ) trata sobre si el navegador envía la solicitud. CORS no impide CSRF: la solicitud se puede enviar y procesar incluso cuando JavaScript no puede ver la respuesta.

Para las API de cambio de estado que usan cookies, aún se necesitan tokens CSRF o cookies de SameSite. CORS no los reemplaza.

El caché de verificación previa

Las respuestas de verificación previa se pueden almacenar en caché a través de Access-Control-Max-Age. Las edades máximas largas (más de 24 horas) reducen los gastos generales: cada combinación distinta (método, URL, encabezados) no vuelve a realizar una verificación previa hasta que caduque. Las edades máximas cortas pueden acumular una latencia significativa.

Patrones CORS comunes en 2026

API públicas: Access-Control-Allow-Origin: * para puntos finales sin autenticación.
API autenticadas: repite el origen de llamada si está en una lista de permitidos, con Access-Control-Allow-Credentials: true.
SaaS API: listas de permitidos por cliente configuradas por customer.
JS Entrega del SDK: archivos estáticos con CORS amplio, a menudo el patrón de API pública.

Preguntas frecuentes

¿Por qué mi recuperación falla con un error CORS?: El servidor al que llama no incluía el encabezado Access-Control-Allow-Origin apropiado para su origen. O el servidor debe estar configurado para permitirle, o debe llamarlo desde el mismo origen (normalmente a través de un proxy backend).
¿Puedo omitir CORS como desarrollador?: Desde su propio código en el navegador, no: el navegador lo aplica. Desde su propio servidor (código backend), sí, porque CORS no se aplica a solicitudes de servidor a servidor. La solución común es un proxy de backend: su frontend llama a su backend; su backend llama a la API de terceros.
¿Cors protege mi API?: No directamente. Se puede acceder a la API independientemente de CORS: el navegador aún envía la solicitud. La protección es que JavaScript en otros sitios no puede leer las respuestas. Para proteger realmente la API, utilice autenticación y autorización en el servidor.
¿Debo usar Access-Control-Allow-Origin: *?: Solo para API públicas que no aceptan credenciales. Para cualquier cosa que tenga cookies o encabezados de autorización, utilice orígenes específicos o haga eco del origen de llamada (con validación). Los navegadores no permiten credenciales comodín +.
¿Por qué CORS realiza una verificación previa solo de algunas solicitudes?: Las solicitudes simples (GET, HEAD, POST con tipos de contenido básicos y sin encabezados personalizados) están exentas; son equivalentes a lo que los formularios HTML ya podían hacer antes de que existiera CORS. Las solicitudes complejas no tienen ningún formato HTML análogo, por lo que realizan una verificación previa para darle al servidor la oportunidad de rechazarlas antes de cualquier cambio de estado.