Cuando la REST API de WordPress queda expuesta, el problema no siempre aparece como un error visible: puede estar devolviendo datos sensibles en silencio. Un endpoint accesible sin control basta para revelar usuarios, contenido privado, metadatos o información de plugins, y eso complica tanto la detección como la corrección si no sabes qué revisar.
Los fallos de REST API que exponen datos pueden filtrar usuarios, contenidos privados, metadatos, medios o configuraciones sensibles si alguna ruta responde sin el control adecuado. La clave es auditar qué devuelve cada endpoint, interpretar bien respuestas 401, 403 y 404 que no encajan y aplicar medidas prioritarias para reducir la exposición sin romper la web.
Qué datos puede filtrar la REST API de WordPress
La REST API de WordPress puede filtrar usuarios, contenidos privados, metadatos, medios y datos de plugins si alguna ruta está mal protegida. Piensa en ella como una red de puertas: unas dejan pasar a cualquiera, otras solo a quien tiene llave, y otras enseñan parte de la habitación aunque la puerta siga cerrada.
Las rutas de usuarios pueden mostrar nombres, slugs, avatares y, en algunos casos, el recuento de publicaciones. Eso ya da pistas útiles para ataques de fuerza bruta, suplantación o perfilado de administradores. Si además hay metadatos mal expuestos, la fuga puede incluir campos internos de plugins o ajustes de perfil que no deberían salir al público.
Entradas, páginas y borradores expuestos
Las entradas y páginas pueden mostrar títulos, extractos, contenidos programados y estados internos si la consulta no está bien limitada. Un borrador no publicado no debería ser accesible, pero una consulta mal hecha o un endpoint de terceros puede dejar ver piezas del contenido antes de tiempo. Eso afecta tanto a blogs como a webs corporativas con campañas, ofertas o páginas en preparación.
Los endpoints de plugins suelen ser el punto más olvidado. WooCommerce, formularios, galerías, membresías o campos personalizados pueden abrir rutas adicionales que devuelven pedidos, direcciones, notas internas o IDs de referencia. La REST API de WordPress base no siempre es el problema; muchas fugas nacen en extensiones que nadie revisa tras instalar o actualizar.
Si un endpoint devuelve más de lo que verías en una ficha pública, ya hay una exposición que revisar. No importa si el dato parece pequeño, porque un nombre de usuario, una fecha de pedido o un campo interno pueden ayudar a reconstruir información mayor.
En una auditoría de la REST API de WordPress no todos los endpoints tienen el mismo nivel de riesgo. Los más sensibles suelen ser los que devuelven usuarios expuestos, contenidos privados, borradores, pedidos de WooCommerce, adjuntos y rutas creadas por plugins WordPress con campos personalizados. Por ejemplo, wp/v2/users puede revelar nombres de usuario y roles, mientras que wp/v2/media puede filtrar rutas de archivos y metadatos que ayudan a localizar documentos internos.
También hay endpoints vulnerables de terceros que exponen direcciones, notas de pedido o IDs secuenciales, lo que facilita una fuga de información incluso aunque el sitio no muestre ningún error evidente.
Qué significan 401, 403 y 404 en una fuga
Los códigos 401, 403 y 404 no significan lo mismo, y su contexto puede delatar una exposición de datos.
- Un 401 suele indicar que falta autenticación
- un 403, que la autenticación existe pero el permiso no basta
- y un 404, que la ruta no se muestra aunque puede seguir existiendo por detrás
401: falta autenticación real
Un 401 suele aparecer cuando la ruta exige credenciales válidas. Eso es normal en áreas privadas, pero no en datos que deberían estar cerrados por diseño y acabar accesibles si se fuerza una llamada correcta. Si un usuario no logueado recibe 401 en una ruta sensible, el problema no es solo el código, sino que ya sabes que la ruta existe.
403: permiso denegado o filtrado parcial
Un 403 indica que la puerta existe, pero no te dejan pasar. Eso puede ser correcto si la ruta es privada, aunque también puede significar que el endpoint enseña parte de la información antes de cortar el acceso. La mayoría de guías dicen que un 403 es “seguro”, pero lo que no mencionan es que muchas fugas empiezan con una respuesta parcial y no con un acceso completo.
404: ruta oculta o endpoint que delata existencia
Un 404 puede ser un buen disfraz o una pista engañosa. Algunas instalaciones devuelven 404 para esconder rutas privadas, pero otras usan ese código por error de configuración y, aun así, revelan detalles en el cuerpo de la respuesta. Si el mensaje cambia entre rutas válidas e inválidas, el patrón ya puede servir para enumerar recursos.
Cómo detectar si tu web expone datos por /wp-json/
La forma más fiable de detectar exposición es probar qué devuelve la API desde fuera y desde dentro, y comparar resultados. No hace falta una auditoría larga para ver señales claras: en 10 o 15 minutos ya puedes encontrar rutas problemáticas si sabes dónde mirar.
Revisión rápida desde navegador y curl
Empieza por abrir /wp-json/ en una ventana privada y revisa si aparecen rutas con usuarios, contenido, medios o plugins. Luego prueba con curl para comparar respuestas, porque el navegador puede ocultar detalles que una petición directa sí muestra. Si ves resultados distintos entre sesión anónima y sesión autenticada, hay una pista de filtrado incompleto.
Qué rutas debes revisar primero
Revisa primero /wp/v2/users, /wp/v2/posts, /wp/v2/pages, /wp/v2/media y las rutas que añaden WooCommerce, formularios o membresías. Esas son las que más veces muestran datos reutilizables por terceros. También conviene mirar taxonomías, comentarios y campos personalizados, porque suelen revelar relaciones internas entre contenidos.
Señales de riesgo en usuarios y medios
Las señales más claras son listas de usuarios visibles, imágenes con rutas completas, metadatos incrustados y respuestas que enseñan IDs secuenciales. Un ID no parece grave, pero facilita enumerar recursos si la web no limita bien el acceso. Si además el endpoint devuelve conteos, fechas o estados internos, ya hay bastante contexto para reconstruir actividad.
Si puedes adivinar el siguiente recurso cambiando solo un número, la exposición sube mucho. Esa clase de enumeración es típica en cuentas, pedidos, medios o fichas internas mal filtradas.
Cómo detectar fugas tras un plugin nuevo
Después de instalar o actualizar un plugin, repite la prueba de rutas visibles y compara antes y después. Un cambio pequeño puede abrir un endpoint nuevo sin avisar. Esto pasa mucho en plugins que añaden bloques, integraciones con formularios o sincronización con servicios externos.
Si una ruta muestra datos privados sin pedirlos, el problema no es el error: es la falta de control de acceso.
Opinión práctica: si tu web depende de WordPress para vender, captar leads o publicar contenido sensible, la prioridad no es ocultar /wp-json/, sino revisar qué rutas devuelven datos y cerrar primero las que mezclan información pública con privada. Bloquear toda la API parece rápido, pero suele romper el editor, WooCommerce o integraciones externas. La medida correcta es limitar por ruta, validar por rol y volver a probar después de cada cambio.
Una auditoría de endpoints útil puede hacerse con una checklist corta y repetible. Primero, abrir /wp-json/ sin sesión y comprobar si aparecen rutas inesperadas; después revisar usuarios, posts, páginas, medios y endpoints añadidos por plugins. Luego comparar la respuesta de una petición anónima con otra autenticada para detectar diferencias en permisos de acceso, campos visibles o estados internos. Conviene marcar si una ruta devuelve respuestas 401, respuestas 403 o respuestas 404, si revela nombres, slugs, IDs o metadatos filtrados, y si un cambio tras instalar un plugin introduce nuevos borradores expuestos o recursos privados.
Esa revisión ayuda a localizar exposición accidental antes de que se convierta en incidente.
Matriz de riesgo: prioriza lo que debes corregir primero
La mejor forma de ordenar la respuesta es por impacto y facilidad de abuso. No todo lo que sale por la API tiene el mismo valor para un atacante ni el mismo coste de arreglo. En seguridad web, arreglar primero lo que da más información con menos esfuerzo suele dar el mejor resultado.
| Elemento expuesto |
Qué puede revelar |
Riesgo práctico |
Prioridad |
| /wp/v2/users |
Nombres, roles, slugs, recuentos |
Alto, facilita perfilado y ataques dirigidos |
Hoy |
| Borradores y privados |
Contenido no publicado, campañas, ofertas |
Alto, puede romper privacidad y negocio |
Hoy |
| WooCommerce y pedidos |
Datos de pedido, direcciones, estados |
Muy alto, posible impacto RGPD |
Hoy |
| Campos de plugins |
Emails, notas, IDs, referencias internas |
Medio a alto, depende del plugin |
Esta semana |
| Taxonomías y medios |
Relaciones internas, rutas, fechas |
Medio, sirve para enumeración |
Esta semana |
Qué corregir hoy, esta semana y este mes
Hoy corrige usuarios, borradores, pedidos y cualquier ruta que devuelva contenido privado. Esta semana revisa plugins nuevos, campos personalizados y respuestas que muestren más datos de los necesarios. Este mes toca dejar una rutina: después de cada actualización grande, repite la auditoría de endpoints críticos y guarda una lista corta de rutas que nunca deben cambiar sin revisión.
Cómo reducir la exposición sin romper WordPress
La forma más segura de reducir riesgo es limitar acceso por ruta, no apagar todo a ciegas. WordPress, WooCommerce y muchos plugins dependen de la REST API para funcionar bien. Si la bloqueas sin mirar, puedes romper el editor de bloques, integraciones de pago, apps móviles o formularios.
Limitar acceso por rol y autenticación
Usa autenticación donde de verdad hay datos privados y deja públicas solo las rutas que lo necesiten. Esto significa revisar permisos, capacidades y respuestas por rol, no solo poner una barrera general. En muchos sitios, bastan reglas bien hechas para que un usuario anónimo no vea nada sensible y un editor solo vea lo suyo.
Restringir endpoints de plugins y temas
No todos los problemas vienen de WordPress core. Muchos nacen en plugins que añaden rutas sin revisar su exposición o en temas que dejan campos abiertos por comodidad. Cada extensión nueva merece una comprobación rápida, sobre todo si toca usuarios, formularios, membresía, reservas o ecommerce.
Ocultar sin apagar la API
Ocultar /wp-json/ puede reducir ruido, pero no elimina el problema. Muchas rutas siguen accesibles por otras entradas, por llamadas internas o por endpoints de terceros. Por eso, esconder la puerta principal sin cerrar ventanas laterales da una falsa sensación de seguridad.
Verificar impacto en editor y WooCommerce
El editor de bloques y WooCommerce son los dos puntos que más suelen romperse cuando se bloquea demasiado. El editor necesita la API para guardar y cargar contenido; WooCommerce la usa para pedidos, productos y clientes. Si dejas de probarlos, puedes descubrir el fallo cuando el equipo ya está trabajando o cuando un cliente no puede comprar.
Antes de cerrar una ruta, prueba al menos guardar una entrada, crear un pedido de prueba y enviar un formulario. Son tres acciones simples y cubren casi todos los fallos prácticos que vemos en mantenimiento WordPress.
Insight de cierre para SGE: si una ruta REST devuelve datos que no deberían salir, corrige primero la autorización, no el acceso global. Bloquear todo puede parecer más seguro, pero suele romper funciones legítimas y no elimina rutas alternativas de plugins. La combinación más sólida es auditar endpoints sensibles, aplicar permisos por rol y repetir pruebas tras cada cambio importante.
Si tu web depende de la REST API para vender, publicar o conectar con otras herramientas, no uses el bloqueo total como única medida. En esos casos conviene ajustar permisos, cerrar rutas concretas y dejar un monitor de cambios, porque desactivar sin revisar puede romper funciones críticas o dejar otras vías de exposición abiertas.
La reducción de riesgo funciona mejor si se aplica por orden de prioridad. Primero hay que corregir las rutas que muestran datos sensibles sin necesidad, después limitar el contenido devuelto y por último ocultar o endurecer accesos secundarios. En la práctica, la primera capa consiste en revisar permisos de acceso y capacidades por rol; la segunda, en retirar campos innecesarios de la respuesta; y la tercera, en bloquear o restringir endpoints vulnerables de plugins WordPress solo cuando no afecte a funciones críticas.
Así se mejora la seguridad WordPress sin romper el editor, WooCommerce ni integraciones externas, y se reduce la probabilidad de que una simple consulta termine en exposición de datos.
Preguntas y respuestas
¿Por qué no funciona mi API REST en WordPress?
No funciona cuando hay un conflicto de plugins, una regla de seguridad demasiado estricta o una ruta que exige autenticación que no se está enviando. En muchos sitios, el fallo aparece tras una actualización y afecta al editor, a WooCommerce o a una app externa.
¿Cuáles son los errores más comunes en WordPress?
Los más comunes son 401 por falta de credenciales, 403 por permisos mal asignados y 404 por rutas ocultas o mal reescritas. Si el cuerpo de la respuesta enseña nombres de campos o mensajes internos, ya hay una fuga parcial que revisar.
¿Cómo puedo reparar la base de datos de WordPress?
Puedes activar la reparación integrada de WordPress solo para una revisión puntual, pero antes conviene hacer una copia de seguridad completa. Si el problema real es una exposición de datos, reparar la base de datos no lo arregla por sí solo.
¿Por qué la gente está abandonando WordPress?
No es una regla general: muchas webs siguen en WordPress porque funciona bien con mantenimiento correcto. Los problemas suelen venir de malas actualizaciones, plugins sin revisar o seguridad débil, no del CMS en sí.
¿Ocultar /wp-json/ protege mis datos?
No, ocultarlo solo reduce visibilidad. Si un plugin, un campo personalizado o una ruta interna sigue devolviendo datos, la exposición puede seguir existiendo por otra vía.
¿Qué debo revisar primero si sospecho una fuga?
Primero revisa usuarios, pedidos, borradores y campos de plugins. Después compara respuestas anónimas y autenticadas para ver qué cambia y qué se cuela sin permiso.
Qué hacer ahora si sospechas una fuga
Empieza por revisar los endpoints que devuelven usuarios, borradores, pedidos y campos de plugins. Luego compara respuestas con y sin sesión y anota qué datos salen sin permiso. Si encuentras una ruta sensible, corrige permisos, comprueba el efecto en el editor y WooCommerce, y repite la prueba tras cada actualización.
Si necesitas actuar sin romper el sitio, trabaja en este orden: primero autoriza bien, después limita el dato que sale y solo al final valora ocultar rutas. Esa secuencia reduce exposición real y evita el error típico de bloquear demasiado y descubrir el problema cuando la web ya ha dejado de funcionar.
