CORS y REST API en WordPress, solución práctica

Cuando aparecen problemas de CORS y REST API en WordPress, lo habitual no es que falle “la API” en abstracto, sino que el navegador bloquea una petición entre orígenes porque la respuesta del servidor no devuelve las cabeceras HTTP esperadas. En la práctica, esto puede deberse a WordPress, a la configuración del servidor, a un plugin de seguridad, a una CDN, a la caché o al propio origen desde el que se lanza la petición.

Un error CORS, en este contexto, es un bloqueo del navegador ante una solicitud a la WordPress REST API desde otro dominio, subdominio o puerto. Si la respuesta no incluye un origen permitido válido, o falla la petición preflight de tipo OPTIONS, el navegador impide el acceso aunque el endpoint exista y responda correctamente en el servidor.

La forma correcta de resolverlo es diagnosticar dónde se rompen las cabeceras CORS y ajustar solo lo necesario, sin abrir la API más de la cuenta ni introducir configuraciones inseguras en producción.

Qué suele causar el conflicto entre CORS y la REST API en WordPress

WordPress incorpora comportamiento propio para la REST API y puede enviar determinadas cabeceras, pero eso no cubre todos los escenarios de origen cruzado. Si la petición viene desde una app en otro dominio, un frontal desacoplado, un entorno local como localhost:3000 o un subdominio distinto, conviene revisar el conjunto completo de la respuesta del servidor.

• El encabezado Access-Control-Allow-Origin no aparece o devuelve un valor distinto al origen real.
• La petición preflight OPTIONS no se atiende bien y el servidor responde con 403, 405 o redirecciones.
• Hay autenticación con cookies, nonces o credenciales y se intenta permitir *, algo inadecuado en muchos casos.
• Un plugin de seguridad, WAF, CDN o proxy inverso elimina o sobreescribe cabeceras CORS.
• La caché sirve una respuesta antigua sin las cabeceras correctas para ese origen.

También es frecuente confundir un bloqueo CORS con un error de autenticación o permisos. Si el endpoint devuelve 401 o 403, puede haber además un problema de credenciales, cookies o nonce, no solo de origen permitido.

Cómo identificar si el fallo viene de WordPress, del servidor o del navegador

El diagnóstico empieza en la consola del navegador y en la pestaña de red. Ahí puedes comprobar si falla la solicitud principal al endpoint o la preflight previa.

Un ejemplo típico: una SPA en http://localhost:5173 consume /wp-json/ de un dominio en producción. Si el servidor no devuelve ese origen concreto en la respuesta, el navegador bloqueará la llamada aunque el endpoint funcione si lo visitas directamente.

Si la respuesta sale del servidor sin las cabeceras correctas, el problema suele estar fuera del navegador. Si las cabeceras están bien pero sigue fallando con sesión autenticada, conviene revisar nonces, cookies, SameSite y la forma en que se envían las credenciales, sobre todo si necesitas arreglar plugins que rompen tu WordPress.

Solución práctica para permitir peticiones CORS sin abrir más de la cuenta

La solución prudente consiste en permitir solo los orígenes necesarios y validar que el servidor responda de forma coherente a OPTIONS, GET, POST u otros métodos usados por la API. Según el servidor, puede resolverse en Apache, Nginx, PHP o mediante ajustes en WordPress si procede.

Si no hay autenticación ni cookies, a veces se usa * para recursos públicos. Aun así, no conviene darlo por bueno como solución universal. Si intervienen credenciales, el origen debe ser explícito y coherente con el flujo de autenticación.

Access-Control-Allow-Origin: https://app.ejemplo.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-WP-Nonce

Ese patrón puede ser válido en algunos escenarios, pero conviene adaptarlo al entorno real. En WordPress, además, si usas autenticación de la REST API con cookies y nonce, debes comprobar que el frontend envíe correctamente X-WP-Nonce cuando corresponda y que el navegador no esté descartando cookies por política de sitio cruzado.

Si el objetivo es bloquear REST API WordPress para ciertos usos, eso es una decisión distinta a solucionar CORS. Limitar endpoints o acceso autenticado puede ser razonable, pero no sustituye una configuración correcta de cabeceras.

Errores frecuentes al tocar cabeceras, plugins o caché

• Añadir cabeceras CORS duplicadas en WordPress y servidor a la vez, generando respuestas inconsistentes.
• Olvidar la petición preflight y probar solo la URL final del endpoint.
• Permitir cualquier origen mientras se envían credenciales o cookies.
• No purgar caché de servidor, plugin o CDN tras modificar cabeceras HTTP.
• Asumir que un plugin “arregla CORS” sin revisar cómo responde realmente el servidor.

En entornos con Cloudflare, Sucuri, proxy inverso o reglas personalizadas, el origen de la respuesta puede no ser PHP directamente. Por eso, si cambias algo en WordPress y no ves efecto, puede que la cabecera se esté perdiendo antes o después de llegar a la aplicación.

Cuándo conviene escalar la revisión técnica

Si ya has validado consola, preflight, cabeceras, credenciales y caché, pero el error CORS WordPress persiste, suele ser momento de revisar el stack completo. Esto es especialmente recomendable si hay balanceador, contenedores, hosting gestionado, CDN o reglas de seguridad administradas por terceros.

El criterio técnico correcto con CORS y REST API en WordPress no es aplicar una receta fija, sino confirmar qué origen hace la petición, qué responde realmente el servidor y si hay autenticación de por medio. Los errores más comunes vienen de mezclar cabeceras, olvidar la preflight o tocar producción sin purgar caché ni aislar el problema.

Antes de cambiar configuraciones sensibles, lo razonable es revisar WordPress, servidor y caché en un entorno controlado y replicar la petición exacta que falla. Si la API forma parte de una integración de negocio, una auditoría técnica breve suele ahorrar tiempo y evitar aperturas inseguras.