¿Qué es la API REST de WordPress? Una guía práctica

La API REST de WordPress es una interfaz HTTP incorporada que permite a software externo interactuar con un sitio WordPress a través de JSON. Se fusionó con el núcleo de WordPress en la versión 4.7 (diciembre de 2016) y es la base del editor de bloques Gutenberg, las apps móviles oficiales de WordPress, cada frontend de WordPress headless y un enorme número de integraciones de plugins. El endpoint base es /wp-json/ en cada sitio WordPress. Muchos de estos endpoints son públicos por defecto, lo cual normalmente está bien, pero algunos de ellos (sobre todo la lista de usuarios) exponen información que la mayoría de los propietarios de sitios preferiría mantener privada.

¿Qué es la API REST de WordPress, en términos concretos?

La API REST es la interfaz programática del sitio WordPress. Donde un navegador visita una URL como example.com/sample-post/ y recibe HTML, un cliente de API solicita example.com/wp-json/wp/v2/posts y recibe JSON: un array de objetos de post con sus títulos, contenido, fechas, IDs de autor, etc. Cada operación CRUD (crear, leer, actualizar, eliminar) que WordPress puede realizar a través de su UI de administración tiene un endpoint REST correspondiente. El editor de bloques llama a estos endpoints cuando guardas una entrada; las apps móviles los llaman al publicar desde tu teléfono; las configuraciones headless los llaman para obtener contenido para un frontend Next.js o Gatsby.

Algunos endpoints canónicos a conocer:

• /wp-json/ — el endpoint de discovery. Devuelve un documento JSON que describe todas las rutas disponibles en el sitio.
• /wp-json/wp/v2/posts — lista de entradas del blog. Pública por defecto.
• /wp-json/wp/v2/pages — lista de páginas.
• /wp-json/wp/v2/users — lista de autores y sus perfiles públicos. El endpoint que causa más preocupación.
• /wp-json/wp/v2/media — lista de elementos de la biblioteca de medios.
• /wp-json/wp/v2/categories, /tags, /comments — exactamente lo que parece.

Plugins y temas pueden registrar endpoints adicionales. WooCommerce añade /wp-json/wc/v3/products, /orders, /customers. ACF añade endpoints para campos personalizados. Contact Form 7, Yoast SEO, cada plugin importante tiene su propio subconjunto de la API REST.

¿Qué hace la API REST de WordPress que debería interesarme?

Tres casos de uso de alto impacto, incluso si nunca escribes una línea de código tú mismo:

• El editor Gutenberg depende de ella. Cada vez que guardas una entrada en el editor de bloques, el editor llama a POST /wp-json/wp/v2/posts/{id}. Si la API REST está rota o bloqueada, Gutenberg deja de funcionar. Síntomas: errores "Actualización fallida" o "La respuesta no es una respuesta JSON válida" al guardar. La causa más común es un plugin de seguridad o una regla .htaccess demasiado agresiva que bloquea /wp-json.
• Es el objetivo de reconocimiento de ataques más común. Atacantes consultando /wp-json/wp/v2/users pueden enumerar cada cuenta de autor: nombres de usuario, nombres de visualización y la ruta URL de su archivo de autor. A partir de ahí, sigue el adivinado de contraseñas o el phishing dirigido. Este único endpoint es responsable de la mayoría de los hallazgos de "nombres de usuario filtrados" en auditorías de seguridad de WordPress.
• Permite toda integración externa. Zapier, Make, IFTTT, notificaciones de Slack personalizadas, sincronización con un CRM, sincronización con un generador de sitios estáticos, sincronización con MailChimp, servicios de traducción de terceros, cada integración usa la API REST. Deshabilitarla por completo (lo que recomiendan algunos tutoriales de seguridad) rompe todas estas.

¿Qué información expone la API REST por defecto?

Listo para usar, una solicitud sin autenticación a un sitio WordPress típico puede recuperar:

• Todas las entradas y páginas publicadas. Incluyendo su contenido completo. Los mismos datos que un navegador visitando el sitio puede ver; solo en forma JSON para un scraping más fácil.
• La lista de cada usuario que ha publicado una entrada. /wp-json/wp/v2/users devuelve el nombre de usuario de WordPress (el nombre de login), el nombre de visualización, la URL del archivo de autor y el ID del usuario para cada autor. Esto se cambió en WordPress 5.0 para devolver solo usuarios que hayan publicado una entrada (anteriormente devolvía cada usuario), pero para la mayoría de los blogs eso todavía significa cada administrador y editor.
• Todos los elementos de la biblioteca de medios. Incluyendo las URLs de tamaño original para cada imagen y archivo. Útil para scraping, dañino si subiste documentos privados a la biblioteca de medios pensando que no serían detectables.
• La taxonomía completa. Categorías, etiquetas, taxonomías personalizadas y sus relaciones.
• Metadatos del sitio. Nombre, descripción, URL, zona horaria, idioma, formato de tiempo, tipos de entrada disponibles y taxonomías.

Nada de esto es técnicamente una vulnerabilidad; es la API comportándose como está diseñada. Pero para la mayoría de los sitios el trade-off entre "conveniencia para integraciones" y "filtración de información para atacantes" se inclina hacia restringir al menos el endpoint de usuarios.

¿Debería deshabilitar la API REST de WordPress?

Respuesta corta: no, no la deshabilites por completo. Restríngela.

Deshabilitar la API REST por completo rompe el editor de bloques para cualquier admin logueado tratando de guardar una entrada, rompe la app móvil de WordPress, rompe cada automatización de Zapier o Make apuntando al sitio, rompe el checkout de WooCommerce en algunas configuraciones, y rompe cada plugin que usa la API REST internamente (que ahora es la mayoría de los plugins). El consejo "deshabilita la API REST" de artículos de seguridad antiguos data de WordPress 4.7-4.9 cuando la API era más nueva y la historia de la integración estaba menos desarrollada. En 2026 está equivocado.

El enfoque correcto es restringir endpoints específicos (especialmente /users) mientras se deja funcionando el resto de la API. Tres patrones que logran el equilibrio correcto:

Patrón 1: requerir autenticación para el endpoint de usuarios

La restricción más común y útil. Añade al functions.php de un child theme o a un mu-plugin:

add_filter('rest_authentication_errors', function ($result) {
    if (!empty($result)) {
        return $result;
    }
    $route = isset($GLOBALS['wp']->query_vars['rest_route']) ? $GLOBALS['wp']->query_vars['rest_route'] : ';
    if (strpos($route, '/wp/v2/users') === 0 && !is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            'You are not currently logged in.',
            ['status' => 401]
        );
    }
    return $result;
});

Esto devuelve un 401 a solicitudes sin autenticar a /wp-json/wp/v2/users mientras deja accesibles todos los demás endpoints. Las apps móviles e integraciones que se autentican (Application Passwords, OAuth) siguen funcionando normalmente. Gutenberg sigue funcionando porque la solicitud del editor está autenticada.

Patrón 2: limitar la tasa de la API

Un scraper de alto volumen golpeando /wp-json/wp/v2/posts?per_page=100&page=N puede extraer toda tu base de datos de contenido en segundos. El rate-limiting a nivel de servidor web (nginx limit_req) o vía un plugin de seguridad (Wordfence, iThemes Security) atenúa esto. Protección útil contra scrapers de contenido y enumeración por fuerza bruta incluso cuando endpoints individuales no son sensibles.

Patrón 3: usar un WAF o CDN que filtre solicitudes de API

Cloudflare y Sucuri permiten escribir reglas como "bloquea cualquier solicitud a /wp-json/wp/v2/users desde fuera del rango de IP de nuestra empresa". Útil para sitios donde la API REST es puramente interna (un backend headless de un equipo editorial, por ejemplo).

¿Cómo se autentica la API REST de WordPress?

Para operaciones de escritura o para acceder a datos no públicos, la API REST requiere autenticación. Cinco métodos, en orden de cuán comunes son en 2026:

• Autenticación por cookie. El default para solicitudes que se originan desde el mismo sitio que la instalación de WordPress. El editor de bloques y cualquier solicitud de UI de admin logueada usan cookies. Requiere un nonce para protección CSRF.
• Application Passwords. Introducido en WordPress 5.6 (2020). Cada usuario puede generar contraseñas específicas de propósito desde su página de perfil, que luego se envían vía HTTP Basic Auth. Este es el método recomendado para apps móviles e integraciones externas a 2026. La mayoría de plugins que anteriormente requerían JWT ahora también soportan Application Passwords.
• OAuth 2.0. Vía el plugin oficial "WordPress.com" o plugins OAuth de terceros. Usado cuando necesitas alcances de grano fino o integración de apps de terceros. Menos común que Application Passwords para la mayoría de los casos de uso.
• JWT (JSON Web Tokens). Vía el popular plugin "JWT Authentication for WP REST API". Fue el estándar de facto para WordPress headless entre 2017 y 2022, ahora mayormente reemplazado por Application Passwords.
• Autenticación específica del plugin. WooCommerce usa claves de consumidor firmadas con HMAC para su API. Cada plugin importante tiende a tener su propio enfoque.

Si estás escribiendo código personalizado o pidiendo a un desarrollador que se integre con tu sitio, la respuesta por defecto en 2026 es "Application Passwords" a menos que tengas una razón específica para usar OAuth o JWT.

¿Cómo verifico qué expone la API REST de mi sitio?

Tres comprobaciones rápidas:

1. Visita el endpoint de discovery. Abre https://tusitio.com/wp-json/ en un navegador. Obtendrás un documento JSON listando cada ruta registrada. Lee a través del objeto routes para ver qué está disponible.
2. Comprueba el endpoint de usuarios específicamente. Visita https://tusitio.com/wp-json/wp/v2/users. Si ves un array de usuarios con nombres, slugs y enlaces, los nombres de tus autores son públicamente enumerables. Si ves {"code": "rest_not_logged_in", "message": "..."}, está restringido. Si obtienes un 404, toda la API REST está deshabilitada (lo que probablemente significa que Gutenberg tampoco funciona).
3. Usa InspectWP. La sección de Seguridad de un reporte InspectWP testea explícitamente si el endpoint de usuarios es accesible públicamente y lo marca si lo es. Más rápido que escribir las URLs manualmente.

¿Cuál es la diferencia entre la API REST y XML-RPC?

WordPress tiene dos APIs remotas que se superponen en propósito: XML-RPC (legado, desde WordPress 2.6 en 2008) y la API REST (moderna, desde 4.7 en 2016). Para la mayoría de las operaciones exponen funcionalidad comparable. Las diferencias:

• Protocolo. XML-RPC usa XML sobre POST a un único endpoint (/xmlrpc.php). La API REST usa JSON sobre verbos HTTP estándar en múltiples URLs. JSON es significativamente más fácil de trabajar en lenguajes modernos.
• Superficie de ataque. XML-RPC ha sido un dolor de cabeza de seguridad perenne. El método system.multicall permite agrupar miles de intentos de adivinación de contraseñas en una sola solicitud, derrotando el rate-limiting básico. La función Pingback se ha usado en ataques de amplificación DDoS. La mayoría de guías de seguridad ahora recomiendan deshabilitar XML-RPC por completo, lo cual es una conversación diferente a la API REST.
• Futuro. El desarrollo del núcleo de WordPress se ha movido enteramente a la API REST. XML-RPC sigue siendo soportado pero no se añaden nuevas características. Varias herramientas de terceros (notablemente Jetpack, hasta hace poco) todavía dependen de XML-RPC, lo cual es la razón principal por la que sigue habilitado por defecto.

"Deshabilitar XML-RPC" y "asegurar el endpoint de usuarios de la API REST" son ambas medidas de seguridad razonables y apuntan a cosas diferentes. Hacer una no afecta a la otra.

¿Cuáles son problemas comunes de la API REST en sitios WordPress?

• "La respuesta no es una respuesta JSON válida" al guardar en Gutenberg. Casi siempre significa que un plugin de seguridad o regla .htaccess está bloqueando solicitudes /wp-json/, o una configuración de permalink las está reescribiendo incorrectamente. Solución: regenera permalinks (Ajustes, Enlaces permanentes, Guardar) y revisa Wordfence/iThemes por toggles "Bloquear API REST".
• Errores CORS al llamar desde un frontend headless. Por defecto WordPress solo acepta solicitudes API REST de su propio dominio. Para una configuración headless en un dominio diferente, añade cabeceras Access-Control-Allow-Origin vía el filtro rest_pre_serve_request, o usa un plugin como "WP CORS".
• Application Passwords no funcionan. Algunos entornos de hosting eliminan la cabecera Authorization de solicitudes entrantes antes de que WordPress las vea. Esta es la causa más común de "Application Password falla silenciosamente". Solución: pídele al host que ponga en lista blanca la cabecera Authorization para HTTP Basic Auth, o usa el workaround HTTP_AUTHORIZATION en .htaccess.
• Respuestas lentas de la API REST. Default per_page=10, pero una integración perezosa solicita per_page=100 en un sitio con 50.000 entradas. Cada llamada REST carga el objeto post completo, hidrata campos ACF, corre filtros. Resultado: una respuesta de 30 segundos. La solución suele ser añadir una caché de objetos (Redis) y consultar solo los campos que la integración realmente necesita vía el parámetro _fields.
• 404 en /wp-json/ por todas partes. Los permalinks bonitos no están habilitados. Ve a Ajustes, Enlaces permanentes, selecciona cualquier cosa distinta a "Simple", guarda. La API REST requiere permalinks bonitos para funcionar.

Qué verifica InspectWP

La sección de Seguridad de cada reporte InspectWP prueba la API REST de WordPress de dos formas específicas. Primero, comprueba si /wp-json/wp/v2/users es accesible públicamente sin autenticación. Si lo es, el reporte lista los nombres de usuario enumerables y lo marca como un hallazgo de seguridad, porque los nombres de usuario expuestos hacen el brute-force y el phishing dirigido significativamente más fáciles. Segundo, el reporte comprueba si el endpoint de discovery de la API REST es alcanzable en absoluto, lo cual es necesario para que Gutenberg y la mayoría de los plugins funcionen; una API REST completamente deshabilitada se marca como causa probable de problemas del editor. El estado recomendado es "API REST alcanzable, endpoint de usuarios protegido". El objetivo es hacer que las integraciones funcionen mientras se bloquea el patrón de reconocimiento de atacantes más común, lo cual puede lograrse con el pequeño snippet de código mostrado arriba.