Proteger API REST WordPress: guía práctica 2026

En pocas palabras: Protegé la API REST de WordPress cerrando la enumeración de usuarios en /wp-json/wp/v2/users, exigiendo autenticación con Application Passwords —nativo desde WordPress 5.6— o JWT, y aplicando rate limiting. Todo se implementa sin tocar el core, mediante código en functions.php, plugins de seguridad o reglas del servidor.

Para proteger la API REST de WordPress de accesos no autorizados necesitás tres capas: cerrar la enumeración de usuarios en /wp-json/wp/v2/users, exigir autenticación con Application Passwords o JWT, y aplicar rate limiting. Las tres se implementan hoy mismo, gratis y sin tocar el core.

La API REST de WordPress es la interfaz que expone contenido y funciones del sitio en formato JSON bajo la ruta /wp-json, integrada al core desde la versión 4.7. WordPress la trae habilitada por defecto, así que cualquier visitante puede consultar posts, páginas, comentarios, medios y la lista de usuarios salvo que la restrinjas con código, plugins o reglas del servidor.

¿Por qué la API REST de WordPress es un riesgo de seguridad?

Porque viene abierta de fábrica y entrega información valiosa para preparar un ataque: qué usuarios existen, qué contenido hay publicado y qué rutas responden en tu instalación. No es una puerta trasera exótica. Es la puerta principal, abierta de par en par.

Ponele que le pegás a misitio.com/wp-json/wp/v2/users desde cualquier navegador. Sin login, sin captcha, sin nada. Te devuelve la lista completa de usuarios con IDs, nombres y slugs, que son exactamente los datos que alguien necesita para lanzar fuerza bruta contra tu login. Complementá con cómo configurar Sucuri paso a paso. Los tres vectores principales son:

• Enumeración de usuarios: el endpoint de users revela nombres de cuenta válidos, la mitad del trabajo hecho para un ataque de credenciales.
• Fuerza bruta sobre endpoints de autenticación: rutas como jwt-auth/v1/token reciben miles de intentos de contraseña si nadie las limita.
• Exfiltración de datos a escala: scraping masivo de contenido público y metadatos que conviene no regalar.

El tema escaló en 2026: se registró la vulnerabilidad CVE-2026-2009, relacionada con la exposición de usuarios a través de la REST API, según el análisis de ZinRuss. Y no es paranoia aislada: según el informe de sitios comprometidos de Sucuri (2024), el abuso de APIs ya representaba el 23% de los vectores de ataque analizados. Cualquiera que haya administrado un WordPress con tráfico sabe que esos scans llegan solos, todos los días, desde que el sitio sale al aire.

¿Cómo bloquear la enumeración de usuarios por REST API?

Filtrando rest_endpoints para eliminar las rutas de usuarios cuando quien consulta no está logueado. Son pocas líneas, cubren tanto el listado como el detalle individual por ID, y no rompen el panel de administración:

add_filter( 'rest_endpoints', function( $endpoints ) {
 if ( ! is_user_logged_in() ) {
 unset( $endpoints['/wp/v2/users'] );
 unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
 }
 return $endpoints;
} );

Ese código va en el functions.php de tu tema hijo o en un plugin de utilidades. Si preferís no tocar código, tenés dos caminos más:

• Plugin gratuito Disable WP REST API: corta el acceso a la API completa para visitantes no logueados. Rápido, pero de tijeretazo.
• Bloqueo selectivo por endpoint: en vez de apagar todo, eliminás solo las rutas sensibles (users) y dejás el resto funcionando para plugins y el editor.

Ojo con esto: actualizás el plugin, limpiás caché, probás el endpoint en el navegador, funciona, cerrás todo, te dormís tranquilo y a la mañana el cliente te escribe porque el formulario de contacto no manda nada, resulta que el plugin de formularios consultaba la REST API por debajo y nadie lo documentó. Antes de dar por cerrado el tema, verificá también la variante ?rest_route=/wp/v2/users, que muchos bloqueos ignoran y que BlackBox Radar documenta con detalle.

¿Cuáles son los métodos de autenticación disponibles en la API REST de WordPress?

Cuatro, en la práctica: Application Passwords (nativo desde WordPress 5.6), tokens JWT vía plugin, Basic Auth y OAuth 2.0. Para la mayoría de los casos, Application Passwords alcanza y no requiere instalar absolutamente nada. La comparación rápida:

¿Y si tu sitio todavía no tiene HTTPS? Eso va antes que cualquier otra cosa de esta lista. Sin cifrado, Basic Auth es tirar la contraseña en texto plano y esperar que nadie mire. Lo explicamos a fondo en activar la autenticación en dos pasos.

¿Cómo implementar rate limiting para prevenir ataques de fuerza bruta?

Limitando la cantidad de solicitudes que una misma IP puede hacer a la API en un período dado, idealmente en tres niveles: borde (Cloudflare o el firewall del hosting), plugin de seguridad y, si hace falta, código propio. Como referencia de trabajo: entre 100 y 1000 requests por hora por IP según el endpoint, con bloqueo progresivo después de 5 a 10 intentos fallidos seguidos.

• Firewall de borde: las reglas de rate limiting de Cloudflare filtran los picos antes de que lleguen a tu servidor, sin consumir recursos de PHP.
• Plugins de seguridad: Wordfence, WP Cerber y Shield Security traen límites configurables; Shield Security explica su enfoque de rate limiting aplicado a la API y a XML-RPC.
• Código PHP: un contador con transients que corte la IP tras N fallos. Funciona, aunque duplicás lo que el firewall ya puede hacer.

El caso típico donde esto salva: el endpoint jwt-auth/v1/token recibiendo cientos de POST por hora probando combinaciones. Si solo protegés wp-login.php, te quedaste mirando la puerta equivocada.

¿Qué es un permission_callback y cómo asegura tus endpoints personalizados?

Es la función que le dice a WordPress quién puede ejecutar un endpoint registrado con register_rest_route(), y desde WordPress 5.5 es obligatoria: si falta, el endpoint devuelve error en lugar de funcionar. Es el control de acceso fino que muchos desarrolladores se saltan por apuro:

register_rest_route( 'miapp/v1', '/datos', array(
 'methods' => 'GET',
 'callback' => 'mi_funcion_datos',
 'permission_callback' => function () {
 return current_user_can( 'edit_posts' );
 },
) );

Para rutas públicas, '__return_true'. Para rutas protegidas, current_user_can() con la capability correcta. El error clásico: copiar '__return_true' de un tutorial en un endpoint que devuelve datos privados. Y validá siempre los parámetros de entrada con sanitize_text_field() o absint(); la documentación oficial de endpoints personalizados cubre el patrón completo.

¿Conviene desactivar toda la API REST de WordPress o solo proteger ciertos endpoints?

Casi nunca conviene desactivarla completa: el editor de bloques, muchos formularios de contacto y temas modernos dependen de ella, así que la restricción selectiva suele dar la mejor relación entre seguridad y funcionamiento. ¿Querés comprobarlo? Cortala entera y mirá cómo el editor deja de guardar borradores al toque. En implementar la verificación en dos pasos profundizamos sobre esto.

Dicho esto, hay casos donde el apagón total zafa:

• Sitio vitrina estático: sin app móvil, sin headless, sin formularios que usen la API por debajo.
• Instalaciones viejas o de prueba: un WordPress desactualizado que no vas a mantener mejor lo tiene cerrado del todo.
• Entornos de staging: donde nadie debería consultar nada desde afuera.

Después de cada cambio, probá tres cosas: que el editor guarde, que los formularios envíen y que los endpoints que sí querés públicos sigan respondiendo. La guía de DonWeb para deshabilitar la REST API y esta guía de Besap detallan ambos caminos, el total y el quirúrgico.

¿Cómo bloquear wp-json en .htaccess o Nginx?

Con reglas de rewrite que devuelvan 403 para /wp-json/ y para el parámetro rest_route, dejando una excepción para usuarios logueados si querés conservar el editor. En Apache:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/ [OR]
RewriteCond %{QUERY_STRING} rest_route=
RewriteRule ^(.*)$ - [F]

En Nginx:

location /wp-json/ { deny all; }
if ($args ~* "rest_route=") { return 403; }

La versión estricta bloquea también a tus editores, así que sumá una condición que excluya la cookie wordpress_logged_in si el equipo publica contenido. Ojo: algunos paneles de hosting compartido no te dejan editar estos archivos ni ver los logs; si estás evaluando proveedores, fijate que den acceso al .htaccess y a los registros, algo que donweb.com incluye en sus planes de hosting.

¿Cómo saber si alguien está accediendo sin autorización a tu API REST?

Revisando los access logs del servidor en busca de GET /wp-json/wp/v2/users y contando respuestas 401 y 403 repetidas desde la misma IP. Un grep simple sobre el log de la semana te dice si te están escaneando. Los plugins de seguridad ayudan: Wordfence muestra el tráfico en vivo y Shield Security registra los intentos bloqueados, así que no necesitás ser un ninja de la consola para detectarlo.

Herramientas y plugins para proteger la API REST de WordPress

Hay cinco opciones que cubren casi todos los escenarios, según las guías de WP Winners sobre endpoints:

• Disable WP REST API: gratuito y directo, corta la API para visitantes no logueados. Perfecto para sitios vitrina.
• Wordfence: firewall con rate limiting, escaneo de malware y tráfico en vivo para detectar scans contra /wp-json.
• Shield Security: límites de velocidad específicos para la API REST y XML-RPC, con bloqueo progresivo automático.
• WP Cerber: restricciones granulares por endpoint y por usuario, ideal cuando necesitás abrir algunas rutas y cerrar otras.
• Sucuri: WAF en la nube que filtra el abuso de API antes de que toque tu servidor, más monitoreo continuo.

Errores comunes al proteger la API REST de WordPress

• Bloquear /wp-json/ sin excepción para logueados: el editor de bloques deja de guardar y el sitio parece roto. Corrección: excluí la cookie wordpress_logged_in en la regla, o usá el filtro PHP en vez del bloqueo total por .htaccess.
• Ignorar el parámetro ?rest_route=: bloqueaste /wp-json/ y creés que ganaste, pero la variante de query string sigue respondiendo. Corrección: testeá siempre las dos formas de URL antes de celebrar.
• Dejar ‘__return_true’ en endpoints sensibles: el callback copiado del tutorial deja la ruta abierta a cualquiera. Corrección: revisá cada permission_callback y reemplazalo por current_user_can() donde corresponda.
• Rate limiting solo en wp-login.php: mientras cuidás esa puerta, jwt-auth/v1/token y xmlrpc.php siguen abiertos. Corrección: aplicá los límites a nivel de servidor o WAF, que cubren todas las rutas a la vez.

Preguntas Frecuentes

¿Cómo desactivar la API REST de WordPress de forma segura?

Lo más seguro es filtrar rest_endpoints en functions.php manteniendo el acceso para usuarios logueados, o usar el plugin gratuito Disable WP REST API. Evitá el bloqueo total por .htaccess salvo en sitios estáticos, porque rompe el editor de bloques y los formularios que dependen de la API.

¿Cuál es la mejor forma de autenticar la API REST de WordPress?

Application Passwords, nativo desde WordPress 5.6, es la mejor opción para la mayoría de los casos: no requiere plugins, se genera desde el perfil de usuario y se puede revocar individualmente. Para apps móviles o SPAs conviene JWT, y OAuth 2.0 queda reservado para integraciones de terceros. Te puede servir nuestra cobertura de reforzar la seguridad de tu WordPress.

¿Cómo evitar que enumeren usuarios a través de la API REST?

Eliminando las rutas /wp/v2/users y /wp/v2/users/{id} con el filtro rest_endpoints cuando el visitante no está logueado. Verificá después la variante ?rest_route=/wp/v2/users, que muchos bloqueos pasan por alto, y controlá también los archivos de autor en el frontend.

¿Qué es un permission callback y por qué es importante?

Un permission callback es la función que define quién puede ejecutar un endpoint registrado con register_rest_route(). Desde WordPress 5.5 es obligatorio: sin él, el endpoint devuelve error. Es la diferencia entre una ruta pública y una que exige permisos reales.

¿Cómo limitar la velocidad de solicitudes a la API REST?

Con rate limiting en tres niveles posibles: reglas de Cloudflare en el borde, plugins como Wordfence, WP Cerber o Shield Security, o código PHP con transients. Una referencia razonable es entre 100 y 1000 requests por hora por IP, con bloqueo progresivo tras 5 a 10 intentos fallidos.

Conclusión

La API REST de WordPress sigue siendo, en 2026, la superficie de ataque más descuidada de las instalaciones típicas: abierta por defecto, con la lista de usuarios servida en bandeja y el registro de CVE-2026-2009 como recordatorio de que el problema no es teórico. Lo que cambió es que ya no hay excusas: las herramientas son gratuitas y la implementación lleva menos de una hora. Mi recomendación concreta: aplicá hoy el filtro rest_endpoints, generá Application Passwords para cualquier integración y activá rate limiting a nivel de servidor o WAF. Después, probá con curl que /wp-json/wp/v2/users devuelva 401 o 403. Si eso responde bien, dormís más tranquilo.

Fuentes

• WordPress Developer Resources – Documentación oficial de endpoints personalizados y permission callbacks
• Besap – Guía para desactivar la API REST de WordPress y proteger wp-admin
• BlackBox Radar – Exposición de usuarios vía REST API: verificación y cierre seguro
• ZinRuss – Análisis de la vulnerabilidad CVE-2026-2009 de enumeración de usuarios
• Shield Security – Rate limiting para WordPress y protección de la API
• DonWeb – Guía para deshabilitar la REST API en WordPress