¿Tienes un archivo Docker Compose? Tu proyecto se publica en segundos, con un solo comando en cdn.com.tr. Ver cómo ¿Creaste tu app con IA? De la carpeta a producción con un comando — sin git ni registry: cdnctl deploy. Ver cómo ¿Tu código en GitHub? Cada push se despliega solo en cdn.com.tr — conecta tu repo y listo. Ver cómo

Ayuda de CDN.com.tr

Cabeceras CORS en el edge

Añada Access-Control-Allow-Origin y las demás cabeceras CORS a las respuestas de una regla de entrega, deje que su origen responda a las solicitudes OPTIONS de preflight y permita en el WAF los métodos que usa su API.

Caché, seguridad, WAF y purga

Cabeceras CORS en el edge

Añada Access-Control-Allow-Origin y las demás cabeceras CORS a las respuestas de una regla de entrega, deje que su origen responda a las solicitudes OPTIONS de preflight y permita en el WAF los métodos que usa su API.

Guías relacionadas

Cómo funciona CORS en el navegador, cómo leer una solicitud que el edge rechazó y qué más recibe su origen del edge.

Contexto

Qué es CORS: la regla del navegador detrás de cada error cross-origin

Solicitudes simples, preflights y credenciales, con pruebas en curl.

Leer la guía
Un 403 del edge

Leer registros de WAF

Encuentre una solicitud rechazada por hora o por Reference ID y vea qué regla la bloqueó.

Abrir el tema
Su origen

Conexión con el origen: la IP real del visitante, el bloqueo de su origen, WebSocket y tiempos de espera

Las cabeceras que se envían a su origen y los métodos del WAF que necesita una API.

Abrir el tema

Ruta en el panel

  1. Panel de gestión
  2. Reglas de entrega
  3. Reglas
  4. Editar
  5. Cabeceras
  6. Añadir cabeceras de respuesta

Requisitos previos

  • Una regla de entrega que sirva las rutas que solicita el otro sitio.
  • El origen exacto del sitio que hace la solicitud, como https://app.example.com, o * para archivos que cualquiera puede cargar.
  • Para las llamadas a la API que envían un preflight: su origen responde a OPTIONS en esas rutas con 200 o 204.
  • El rol de propietario o editor: los lectores pueden ver las reglas, pero no cambiarlas.

Modelo de decisión

¿Archivos públicos o una API?

Lo que envía el navegador decide dónde se hace el trabajo.

  • Fuentes, imágenes y JSON público cargados con un GET simple: no hay preflight, y Access-Control-Allow-Origin en la regla es todo lo que necesitan. Mientras la optimización de imágenes de toda la cuenta está activada, los archivos .jpg, .jpeg y .png toman las cabeceras de respuesta de la regla más antigua del dominio, no las de la regla de su ruta.
  • Llamadas a la API con cuerpos JSON, cabeceras personalizadas o PUT, PATCH, DELETE: el navegador envía antes un preflight; su origen lo responde, y la regla puede añadir las cabeceras CORS a esa respuesta.
  • Solicitudes con cookies u otras credenciales: un único origen concreto, no *, más Access-Control-Allow-Credentials true.

¿Cada cabecera desde el edge o desde su origen?

Elija una sola fuente por cabecera.

  • Edge (la regla): un valor fijo en cada respuesta 2xx y 3xx, incluidas las servidas desde la caché, y también en las respuestas 4xx y 5xx de su origen si la línea termina en always.
  • Origen: un valor que depende del sitio que hace la solicitud, enviado con Vary: Origin.
  • Enviada por ambos: márquela en Quitar cabeceras, para que solo salga el valor de la regla.

Guía paso a paso

1

Añada las cabeceras a la regla

Ejemplo para una API en /api/ a la que llama una aplicación web. Escriba una cabecera por línea; un valor con espacios va entre comillas dobles.

  • Abra Reglas de entrega → Reglas y pulse Editar en la regla de /api/.
  • En Entonces → Cabeceras, escriba en Añadir cabeceras de respuesta, cada una en su propia línea: Access-Control-Allow-Origin https://app.example.com, Access-Control-Allow-Methods "GET, POST, PUT, OPTIONS", Access-Control-Allow-Headers "Content-Type, Authorization" y Access-Control-Max-Age 600.
  • En Quitar cabeceras, marque cualquiera de estos nombres que su origen también envíe.
  • Pulse Guardar regla.

Resultado esperado: La regla muestra una etiqueta como +4 cabeceras de respuesta, y la página muestra Publicado en cuanto el edge la sirve.

2

Permita los métodos de la API en el WAF

Necesario mientras el WAF de todo el sitio está activado y la API usa métodos además de GET, HEAD, POST y OPTIONS.

  • En la barra lateral, abra WAF Logs en Protection.
  • En Métodos HTTP permitidos, marque PUT, PATCH o DELETE según lo que necesite su API, mantenga OPTIONS marcado y pulse Save.

Resultado esperado: El panel confirma el guardado, y el cambio se propaga en 1-2 minutos.

3

Compruebe una solicitud simple y un preflight

curl no aplica CORS, así que muestra exactamente lo que responde el edge.

  • Solicite el endpoint con una cabecera Origin.
  • Envíe el preflight que enviaría un navegador: OPTIONS con Origin, Access-Control-Request-Method y Access-Control-Request-Headers.

Resultado esperado: La solicitud simple lleva una sola access-control-allow-origin. El preflight responde 200 o 204 con el origen, los métodos y las cabeceras permitidos.

cdnctl equivalent 
curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)'
curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)'

Verificación

  • curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)' → 2xx y exactamente una access-control-allow-origin: https://app.example.com
  • curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)' → 200 o 204 con access-control-allow-origin, access-control-allow-methods y access-control-allow-headers
  • Un 403 con x-mt-blocked-by: cdn-edge-security en una solicitud → el edge la rechazó (el WAF, o un bloqueo por IP, país, red o hotlink); compruebe Métodos HTTP permitidos y los registros de WAF

Casos de uso

Una aplicación web en app.example.com carga fuentes, JSON o respuestas de API desde www.example.com, y el navegador las bloquea con un error CORS.

Flujo de trabajo rápido

  1. Abra Reglas de entrega, vaya a la pestaña Reglas y pulse Editar en la regla que sirve las rutas que solicita el otro sitio, o Añadir regla para una ruta nueva.
  2. En Entonces, abra Cabeceras y escriba una cabecera por línea en Añadir cabeceras de respuesta con el formato Nombre-Cabecera valor, sin dos puntos, por ejemplo Access-Control-Allow-Origin https://app.example.com. Un valor con espacios va entre comillas dobles.
  3. Si su origen ya envía una cabecera Access-Control-* para estas rutas, marque el mismo nombre en Quitar cabeceras, para que el navegador reciba un único valor.
  4. Pulse Guardar regla (Crear regla en una regla nueva) y espere hasta que la página muestre Publicado.
  5. Si su API usa PUT, PATCH o DELETE y el WAF de todo el sitio está activado, márquelos en Métodos HTTP permitidos en la página Security.
  6. Compruebe con curl una solicitud simple y un preflight.

Verificaciones

  • Las cabeceras de la regla se añaden a las respuestas correctas y de redirección (2xx y 3xx), incluidas las servidas desde la caché, desde el momento en que se publica la regla. Una línea que termina en always se añade también a las respuestas 4xx y 5xx de su origen.
  • Las solicitudes OPTIONS de preflight van a su origen y nunca se almacenan en caché. Cuando su origen responde a un preflight con 200 o 204, las cabeceras de la regla se añaden a esa respuesta; un preflight respondido con 401, 404 o 405 llega al navegador sin ellas, salvo que la línea termine en always. En una regla con Protección con contraseña o una Lista de IP permitidas, el edge responde por sí mismo con 401 o 403 a un preflight que no deja pasar.
  • Al navegador llega exactamente una Access-Control-Allow-Origin: con dos valores, el navegador rechaza la respuesta.
  • Si su origen varía Access-Control-Allow-Origin según el sitio que hace la solicitud, también debe enviar Vary: Origin. El edge mantiene separadas esas variantes siempre que Mantener una sola copia en caché diga lo que diga la cabecera Vary esté desactivado en la regla.
  • Deje sin marcar Access-Control-Request-Method y Access-Control-Request-Headers en Quitar cabeceras: los nombres que se marcan ahí también se quitan de las solicitudes enviadas a su origen, y su origen lee estas dos para responder a un preflight.
  • Con el WAF de todo el sitio activado, GET, HEAD, POST y OPTIONS están permitidos de forma predeterminada. Una solicitud con un método que no está en la lista recibe un 403 sin cabeceras CORS y con X-MT-Blocked-By: cdn-edge-security, que el navegador notifica como un error CORS.
  • Mientras la optimización de imágenes de toda la cuenta está activada, los archivos .jpg, .jpeg y .png reciben las cabeceras de respuesta de la regla más antigua del dominio, no las de la regla de su ruta: ponga la cabecera CORS de esas imágenes en esa regla, con un Access-Control-Allow-Origin fijo. Cuando esa regla más antigua es la regla de comprobación de certificados, no reciben cabeceras de ninguna regla.

Preguntas frecuentes

¿Responde el edge por sí mismo a las solicitudes de preflight?

El edge pasa las solicitudes OPTIONS a su origen y nunca las almacena en caché, así que su origen debe responder al preflight con 200 o 204. Las cabeceras de respuesta de la regla se añaden a esa respuesta: las cabeceras CORS pueden venir de la regla, y su origen solo tiene que aceptar OPTIONS. La excepción: en una regla con Protección con contraseña o una Lista de IP permitidas, el propio edge responde con 401 o 403 a un preflight que no deja pasar.

¿Puede una regla permitir varios sitios?

Una regla añade el mismo valor a todas las respuestas: * o un origen, como https://app.example.com. Para permitir varios orígenes, deje que su aplicación envíe el origen que corresponda junto con Vary: Origin, y no ponga Access-Control-Allow-Origin en la regla. Las solicitudes con cookies u otras credenciales necesitan un origen concreto, no *.

El navegador sigue mostrando un error CORS. ¿Qué compruebo?

Empiece por el estado de la solicitud que falla en el panel de red del navegador. Un 403 con X-MT-Blocked-By: cdn-edge-security viene del edge: búsquelo en los registros de WAF y, si falta su método, añádalo en Métodos HTTP permitidos. Por defecto, cualquier otro 4xx o 5xx llega sin las cabeceras de la regla, así que corrija primero esa respuesta. Una línea que termina en always, como Access-Control-Allow-Origin https://app.example.com always, se añade también a las respuestas 4xx y 5xx de su origen. Después compruebe que llega exactamente una Access-Control-Allow-Origin y que coincide con el sitio que hace la solicitud, esquema incluido.

Mi API usa PUT, PATCH o DELETE. ¿Qué cambio?

Mientras el WAF de todo el sitio está activado, abra la página Security, marque los métodos en Métodos HTTP permitidos y pulse Save; el cambio se propaga en 1-2 minutos. Métodos de solicitud permitidos, en la pestaña Seguridad de Reglas de entrega, abre la misma tarjeta. Mantenga OPTIONS marcado: los navegadores lo envían para los preflights.