integracion

No 'Access-Control-Allow-Origin' header

Tu app ha pedido datos a otro servidor. El servidor ha contestado, pero sin incluir la cabecera que autoriza a tu web a leer esa respuesta, así que el navegador la ha bloqueado antes de entregártela. La respuesta existe: lo que no existe es el permiso para leerla.

Revisado en agosto de 2026

De paso

Ya de paso: ¿tu app está exponiendo datos?

Analízala gratis mientras lees. Tarda treinta segundos y no toca nada.

Solo leemos lo que tu app ya le entrega a cualquier visitante.

Diagnóstico

Por qué te pasa

Es una protección del navegador, no un fallo. Sin ella, cualquier web que visitaras podría pedir datos en tu nombre a los servicios donde tienes sesión abierta y leer las respuestas. Por eso el navegador exige que el servidor diga explícitamente qué webs pueden leerle.

La consecuencia práctica, y lo que más cuesta aceptar, es que **esto no se arregla en tu app**. El permiso lo da quien responde, no quien pregunta. Puedes reescribir tu código cien veces y no cambiará nada: la cabecera tiene que salir del otro servidor.

En la práctica, casi siempre es que el otro extremo no conoce tu dominio nuevo. Con Supabase suele ser que tu dominio no está declarado en la configuración de URLs del proyecto. Con una API tuya, que su configuración de orígenes permitidos sigue teniendo solo la dirección de desarrollo. Con una API de terceros, muchas veces es deliberado: no están pensadas para llamarse desde el navegador, y ahí la solución es llamarlas desde tu servidor.

Lo que este error no significa

  • No significa que tu petición esté mal formada. Ha llegado y se ha ejecutado; lo que se bloquea es la lectura de la respuesta.
  • No significa que tengas que desactivar la seguridad del navegador ni usar extensiones que la saltan. Eso funciona en tu ordenador y en el de nadie más, y es cómo se dan por arreglados problemas que siguen rotos para todos los usuarios.
  • No significa que los datos estén expuestos. Es justo lo contrario: es el navegador siendo estricto con quién puede leer qué.

Solución

Arréglalo tú, gratis

Todo depende de a quién estés llamando. Identifica primero el destino, y luego ve al panel que corresponda.

  1. 01Abre la consola del navegador con F12 y lee el mensaje completo: te dice a qué dirección estabas llamando. Ese destino decide dónde se arregla.
  2. 02Si llamas a Supabase: entra en tu proyecto, Authentication y luego URL Configuration, y comprueba que tu dominio está declarado. Es la causa más frecuente después de conectar un dominio nuevo.
  3. 03Si llamas a una API tuya, el permiso se configura en esa API: tiene que responder autorizando el dominio de tu app. Si esa API también la desplegaste tú en Vercel o Netlify, se configura en su proyecto, no en el de la web.
  4. 04Si llamas a una API de terceros y su documentación no menciona uso desde el navegador, deja de intentarlo desde ahí: hay que llamarla desde una función de servidor tuya, que además evita publicar la clave de esa API.
  5. 05Comprueba que no estás mezclando http y https, y que la dirección no tiene una barra final de más: para esta comprobación, dos direcciones que difieren en eso son orígenes distintos.

Si en la consola ves además la palabra preflight, tu petición lleva cabeceras o un método que obligan al navegador a preguntar antes. Entonces el otro servidor tiene que responder también a esa pregunta previa, no solo a la petición real.

Y esto para la parte de código

Pégaselo tal cual al agente que escribió tu app. Está redactado para que te diga lo que ha hecho, no solo para que lo haga.

Prompt para tu agente

Mi app da un error de CORS diciendo que falta la cabecera Access-Control-Allow-Origin. El mensaje completo es: [PEGA AQUÍ EL MENSAJE DE LA CONSOLA].

Necesito que hagas esto:
1. Dime a qué servicio se está llamando, desde qué parte del código, y si ese servicio es mío o de un tercero.
2. Si es de un tercero y no está pensado para llamarse desde el navegador, crea una función de servidor que haga esa llamada, de forma que el navegador hable solo con mi propio dominio. Aprovecha para que la clave de esa API deje de estar en el navegador.
3. Si el servicio es mío, dime exactamente qué configuración de orígenes permitidos necesita y para qué métodos y cabeceras.
4. Revisa que todas las direcciones a las que llama la app usen https y no tengan barras finales inconsistentes.
5. Añade manejo de error para que un fallo de red muestre un mensaje comprensible en vez de dejar la pantalla vacía.

No propongas desactivar comprobaciones de seguridad del navegador ni soluciones que solo funcionen en mi ordenador.

Si no sale

¿Lo has intentado y sigue sin salir?

O el escáner de arriba ha encontrado algo y prefieres no tocarlo solo. En cualquiera de los dos casos esto ya es de los gordos y merece un humano: no es que no hayas sabido, es que has llegado al punto en que hace falta alguien que entre y lo vea por dentro.

Las 10 primeras apps son gratis. Estoy empezando y necesito casos reales. A cambio te pido permiso para contar después qué me encontré, sin decir de quién era la app ni enseñar tus datos. Sin tarjeta y sin suscripción: cuando se acaben las plazas empezaré a cobrar y lo diré aquí.

Cita a partir de mañana

Agendar revisión

Gratis

durante el lanzamiento

Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.

  • Sesión de trabajo en directo contigo
  • Diagnóstico del error y del riesgo real
  • Te quedas con el arreglo aplicado

Hoy, en cola prioritaria

Rescate exprés

Gratis

durante el lanzamiento

Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.

  • Hueco el mismo día
  • Prioridad sobre las revisiones agendadas
  • Mismo trabajo, antes

Quién

Marc Sala

IT Manager

  • Analista de ciberseguridad certificado por Google

No es un rating anónimo de un marketplace: es la persona que va a entrar en tu app. Reviso el código, encuentro qué falla y lo arreglo contigo delante, explicándote qué ha pasado sin jerga.