Los Problemas con WP-REST y permisos pueden afectar al editor de bloques, una tienda online, una app externa o un plugin tras una actualización, migración o cambio de CDN; identifica el código HTTP, el endpoint, el usuario y el origen antes de cambiar permisos o desactivar seguridad.
Índice
Anuncio
Diagnostica el código HTTP antes de tocar permisos
Un 401, 403 o 500 puede proceder de la autenticación, una capacidad ausente, un firewall o un error de PHP, así que reproduce la petición y modifica solo la causa confirmada.
Lee la respuesta, no solo el número
Abre https://tudominio.es/wp-json/ en una ventana privada: debe devolver JSON, no una página de acceso denegado. Revisa también el cuerpo: rest_not_logged_in indica que la ruta requiere un usuario autenticado y WordPress no ha reconocido una sesión válida; puede deberse a una cookie ausente, caducada o no enviada, no solo a una sesión inválida. rest_cookie_invalid_nonce señala un nonce ausente o caducado, y rest_forbidden confirma que WordPress rechazó una comprobación de acceso.
Usa esta matriz para decidir la prueba
| Código | Causa más probable | Prueba concreta | Corrección segura |
|---|---|---|---|
| 401 | Cookie, nonce o credencial inválida | Compara navegador y curl con credencial | Renueva nonce o contraseña de aplicación |
| 403 | Capacidad ausente o WAF | Busca `rest_forbidden` y logs WAF | Ajusta capacidad o regla limitada |
| 404 | Ruta o enlaces permanentes | Abre `/wp-json/` y guarda enlaces | Revisa `mod_rewrite` y registro |
| 429 | Límite de CDN o firewall | Lee cabeceras y eventos | Reduce frecuencia o ajusta límite |
| 500 | Error PHP o conflicto | Consulta log de PHP | Corrige el fallo registrado |
Si el navegador funciona y curl devuelve 401, revisa la cabecera Authorization, la contraseña de aplicación y la URL antes de cambiar roles.
En la API REST de WordPress hay que diferenciar tres situaciones antes de corregir nada. Una petición no autenticada no identifica a un usuario y, en una ruta protegida, puede devolver rest_not_logged_in y un error 401 de WordPress. Un usuario autenticado pero sin la capacidad necesaria sí llega a permission_callback; normalmente WordPress responde con rest_forbidden y un error 403 de WordPress en JSON. En cambio, si el servidor, un firewall WAF o Cloudflare bloquea la URL antes de ejecutar WordPress, la respuesta suele ser HTML, una página de desafío o una cabecera propia del proxy.
El nonce de WordPress solo protege una sesión basada en cookies frente a solicitudes entre sitios: no sustituye la autenticación de WordPress ni concede capacidades.
Comprueba identidad y capacidades efectivas
Confirma qué usuario llega a WordPress y qué capacidad solicita la ruta, porque el rol visible no siempre refleja los permisos efectivos.
Verifica el permiso que pide la ruta
Revisa register_rest_route en el plugin, tema o mu-plugin y localiza permission_callback. Debe usar current_user_can() con el permiso mínimo necesario; no devuelvas true para resolver temporalmente el error.
Php 'permission_callback' => function ( WP_REST_Request $request ) { return current_user_can( 'edit_post', (int) $request['id'] ); }
Ajusta el acceso sin abrir la ruta
Comprueba el rol del usuario afectado y los ajustes de WooCommerce, membresías, multisitio o plugins que modifican capacidades. Prueba con ese usuario, no con un administrador, y crea una capacidad específica para endpoints propios cuando sea necesario.
Reproduce la petición y localiza el bloqueo
Compara navegador, curl, WP-CLI y logs para identificar si el fallo está en WordPress, el servidor, el CDN o un firewall.
Prueba cada origen con la credencial adecuada
Para Gutenberg usa la sesión del navegador y X-WP-Nonce; para integraciones servidor a servidor, crea una Application Password para un usuario dedicado con el menor rol posible. Comprueba la autenticación con HTTPS:
bash curl -i -u 'api_usuario:xxxx xxxx xxxx xxxx xxxx xxxx' / https://tudominio.es/wp-json/wp/v2/users/me
Lee logs y limita la excepción
Consulta los logs de WordPress, PHP, Apache o Nginx, Cloudflare y el plugin de seguridad, buscando hora, ruta, método y error. Si un WAF bloquea una petición válida, crea una excepción limitada por ruta, método, IP y duración; nunca abras todo /wp-json/.
El método de autenticación debe corresponder al origen de la petición. Para acciones desde el administrador o Gutenberg, la cookie de sesión y X-WP-Nonce son la opción habitual; el nonce debe generarse de nuevo al recargar una sesión caducada. Para una automatización servidor a servidor, una contraseña de aplicación vinculada a un usuario técnico de privilegios mínimos evita compartir la clave normal de la cuenta. Basic Auth mediante un plugin puede servir para una prueba breve y exclusivamente por HTTPS, pero debe retirarse después porque no ofrece por sí solo una gestión avanzada de tokens.
OAuth o JWT resultan más adecuados cuando una aplicación externa necesita autorización delegada, revocación de tokens o acceso de varios usuarios; sus claves, emisores, caducidades y algoritmos deben validarse en el servidor.
Después de una migración, un cambio de dominio o la activación de un CDN, repite una comprobación mínima antes de modificar permisos: abre /wp-json/ en incógnito, ejecuta curl -i contra la misma ruta y compara código, cuerpo y cabeceras con los del navegador. Con WP-CLI, wp user get ID --fields=ID,user_login,roles permite confirmar el rol del usuario de prueba sin iniciar sesión como administrador; después, verifica sus capacidades efectivas con el plugin o la configuración de membresía que las modifica.
Guarda de nuevo los enlaces permanentes si la ruta devuelve 404, comprueba que la URL canónica use HTTPS y revisa las reglas de redirección. En Cloudflare o ModSecurity, compara los eventos con la hora, IP, método y ruta exactos para limitar la regla afectada sin desactivar toda la protección.
Preguntas y respuestas
¿Cómo arreglo un 401 en WP-REST?
Renueva el nonce en el navegador o crea una contraseña de aplicación para un servidor externo. Confirma que Authorization llega al hosting mediante HTTPS.
¿Por qué recibo 403 en /wp-json?
Puede faltar una capacidad o bloquearte Cloudflare, ModSecurity, un WAF o un plugin. rest_forbidden confirma que WordPress recibió la solicitud.
¿Un administrador siempre puede usar la API REST?
No siempre: filtros, multisitio o plugins pueden modificar capacidades efectivas. Prueba con el usuario afectado y revisa permission_callback.
¿Qué autenticación debo usar para WooCommerce?
Usa claves de la WooCommerce REST API o contraseñas de aplicación según la integración. No envíes contraseñas normales de administrador a servicios externos.
¿Cómo sé si Cloudflare bloquea mi endpoint?
Revisa los eventos de seguridad en la misma franja horaria. Una página HTML de bloqueo en lugar de JSON suele confirmar que el rechazo ocurrió antes de WordPress.
¿Puedo desactivar el plugin de seguridad?
Solo durante unos minutos y con una prueba preparada. Es preferible usar modo diagnóstico o una excepción limitada y registrar la regla bloqueada.
¿Qué significa rest_cookie_invalid_nonce?
La cookie de sesión existe, pero el nonce no es válido o ha caducado. Genera uno nuevo y comprueba que se envía en X-WP-Nonce.
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- Solucionar el error de REST API en WordPress — reparawordpress.com
- Wordpress API comprobar permisos de usuario — reddit.com
- Cómo corregir el error de la REST API en WordPress — wp-staging.com
- Permisos 777 y propietarios erróneos que ponen en riesgo
- El hosting compartido no es barato si tu agencia da soporte
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.