Preflight CORS falla en WordPress, solución

Cuando una web muestra un bloqueo CORS en consola, el problema no suele estar en WordPress por sí solo, sino en cómo responde la aplicación, el servidor o una capa intermedia a una solicitud cruzada. En el caso de preflight cors wordpress, el fallo puede romper formularios, integraciones con terceros, accesos al panel, peticiones autenticadas y llamadas a la REST API WordPress.

Una petición preflight es una solicitud OPTIONS que el navegador envía antes de la petición real para comprobar si el origen, los métodos y las cabeceras están permitidos. Si la respuesta OPTIONS no devuelve las cabeceras correctas, o si un proxy, CDN o plugin las modifica, el navegador bloquea la llamada aunque el servidor parezca estar operativo.

Qué significa el error de preflight CORS en WordPress

CORS es una política del navegador para controlar qué orígenes pueden acceder a recursos de otro dominio, subdominio, puerto o protocolo. Por eso, un error cors wordpress puede aparecer incluso si la URL responde bien al abrirla directamente en el navegador o al probarla con una herramienta que no aplica esa política.

Conviene distinguir tres piezas: la petición preflight, la petición real y el bloqueo del navegador. La primera valida condiciones previas; la segunda transporta los datos; y el bloqueo se produce en el cliente cuando la respuesta no cumple lo esperado. En muchos casos, el síntoma visible está en la consola, pero la causa real está en la configuración del servidor o en las cabeceras CORS.

Cuándo se activa el preflight

Suele activarse cuando la llamada a la API usa métodos como POST, PUT o DELETE, cuando envía cabeceras como Authorization o cuando intervienen credenciales, cookies o sesiones. En ese escenario, permitir cualquier origen con un comodín no siempre es válido ni recomendable.

Por qué falla una petición OPTIONS antes de llegar a la REST API

Una respuesta OPTIONS puede fallar antes de llegar a WordPress si el servidor, el reverse proxy, el firewall o el CDN interceptan la solicitud. También puede ocurrir que WordPress responda, pero con cabeceras incompletas, duplicadas o incompatibles con la petición del navegador.

• Falta Access-Control-Allow-Origin o no coincide con el origen permitido.
• No se devuelven los métodos esperados en Access-Control-Allow-Methods.
• Faltan cabeceras solicitadas en Access-Control-Allow-Headers, por ejemplo Authorization o Content-Type.
• Se mezcla * con credenciales, algo que suele ser incoherente para peticiones con cookies o sesión.
• Un plugin de seguridad, una regla WAF o un CDN cachea o altera la respuesta OPTIONS.

Qué revisar en cabeceras, servidor, plugins y CDN

El diagnóstico debe empezar por la respuesta exacta que recibe el navegador, no por suponer que la rest api wordpress está caída. Revisa en la pestaña Network de las herramientas de desarrollo la solicitud OPTIONS y compárala con la petición real.

Puntos de comprobación más útiles

• Código de estado de la respuesta OPTIONS: idealmente debe responder de forma coherente y sin redirecciones inesperadas.
• Cabeceras de respuesta: origen, métodos, cabeceras permitidas y, si procede, credenciales.
• Diferencias entre local y producción: un conflicto con proxy o CDN puede aparecer solo fuera del entorno de desarrollo.
• Plugins que tocan seguridad, caché, cabeceras o autenticación.
• Configuración del servidor en Apache o Nginx, especialmente si se añaden cabeceras en más de un sitio.

Si además usas Cloudflare, un balanceador o un reverse proxy, conviene revisar si la respuesta OPTIONS se filtra, se cachea o recibe cabeceras distintas a las que genera la aplicación.

Cómo solucionar preflight CORS en WordPress paso a paso

1. Identifica el origen exacto. Comprueba si cambia el dominio, subdominio, puerto o protocolo. Una diferencia mínima ya convierte la llamada en solicitud cruzada.
2. Inspecciona la petición OPTIONS. Mira qué método y qué cabeceras solicita el navegador antes de la llamada real.
3. Ajusta las cabeceras de respuesta. El servidor o la aplicación deben devolver un origen autorizado y permitir solo los métodos y cabeceras realmente necesarios.
4. Revisa credenciales y cookies. Si la llamada usa sesión, nonces o Authorization, la configuración debe ser coherente; abrir CORS con comodines puede no funcionar y además puede ser inseguro.
5. Desactiva pruebas conflictivas. En entorno controlado, prueba sin plugins de seguridad, caché o cabeceras para detectar duplicidades.
6. Comprueba logs y capas intermedias. Si WordPress ni siquiera recibe la solicitud, el problema puede estar en el servidor, el firewall o el CDN como en casos de WordPress bloqueado por ModSecurity.

Si necesitas tocar functions.php, un mu-plugin o la configuración del servidor, hazlo con prudencia y preferiblemente en staging. WordPress dispone de filtros y comportamiento propio en la REST API, pero la solución depende del stack completo, no solo del tema activo.

Errores frecuentes al configurar CORS y cómo evitarlos

• Añadir cabeceras CORS en WordPress y también en Apache, Nginx o CDN, generando duplicados.
• Permitir todos los orígenes sin valorar si hay autenticación, cookies o datos sensibles.
• Olvidar que el navegador valida la coincidencia entre lo que pide y lo que el servidor autoriza.
• Confundir un 200 en la URL final con una configuración CORS correcta.
• No probar la llamada desde el mismo contexto real en el que falla: producción, dominio final y capa CDN activa.

Para ampliar la parte específica de la API, puede ser útil revisar la documentación oficial de WordPress sobre la REST API, pero siempre contrastando con la configuración real del servidor y las cabeceras de respuesta.

Cuándo conviene pedir soporte técnico en WordPress

Si el bloqueo afecta a ventas, formularios, integraciones, acceso al panel o automatizaciones, suele ser más eficiente contar con soporte WordPress. También conviene escalarlo cuando intervienen varias capas a la vez: hosting, WAF, plugins, proxy, CDN y autenticación.

En proyectos donde el tiempo de caída tiene impacto de negocio, un servicio de reparar WordPress o mantenimiento WordPress puede ayudar a localizar el origen del conflicto sin aplicar parches inseguros.

En resumen, preflight cors wordpress no se corrige con una receta única: exige revisar cabeceras, capas intermedias y comportamiento real del navegador. El siguiente paso más sensato es validar la respuesta OPTIONS, comprobar logs y aislar plugins o proxies antes de abrir más permisos de los necesarios.