REST API de WordPress: cómo protegerla en 2026

Actualizado el 05/08/2026 — Este artículo fue actualizado con información reciente y secciones nuevas.

La REST API de WordPress es el acceso programático que permite a apps externas, plugins y editores modernos interactuar con tu sitio mediante HTTP. Disponible por defecto desde WordPress 4.7, expone decenas de endpoints bajo /wp-json/ sin autenticación previa. El riesgo: cualquiera que visite tusitio.com/wp-json/wp/v2/users ve tu listado completo de usuarios, y con esos nombres de usuario el resto del ataque de fuerza bruta es automático.

La REST API de WordPress es la interfaz programática nativa del núcleo que expone los datos y funciones del sitio como JSON accesible vía HTTP, sin login por defecto. Registrada desde la versión 4.7 (2016), permite a terceros, plugins y el editor Gutenberg leer, crear, editar y borrar contenido, usuarios y metadatos de forma remota. Por defecto, endpoints públicos como /wp/v2/users, /wp/v2/posts y /wp/v2/media responden sin requerir autenticación. Según datos de Wordfence (2026), la exposición de estos endpoints sigue siendo el vector de ataque más explotado en WordPress, con patrones que combinan enumeración automática de usuarios + ataques de fuerza bruta contra formularios de login. La protección exige tres capas: restringir endpoints públicos, autenticación robusta para acceso legítimo, y rate limiting para bloquear el reconocimiento automatizado.

En 2026, tras la explotación masiva del CVE-2026-4020 (que robó API keys de más de 100.000 sitios WordPress) y el descubrimiento de patrones de ataque cada vez más sofisticados contra la API, proteger la REST API exige decisiones concretas. Este artículo detalla qué endpoints están en riesgo, cómo restringirlos sin romper funcionalidades modernas, y cómo validar que los cambios que hagas realmente funcionan.

En pocas palabras: La REST API de WordPress expone usuarios, posts y datos sensibles sin autenticación por defecto. Para protegerla en 2026 necesitás restringir endpoints públicos, implementar autenticación robusta y activar rate limiting. Sin eso, cualquier bot de reconocimiento lo detecta en minutos.

Cómo funciona una petición a la REST API

Entender el flujo de una petición REST te ayuda a ver dónde y cómo protegerse. El proceso es siempre el mismo, sin importar si viene de un navegador, un script o una app móvil.

• Un cliente dispara el pedido. Un navegador, una app mobile o un script externo hace una solicitud HTTP a una URL específica de WordPress, por ejemplo /wp-json/wp/v2/posts. El método (GET, POST, PUT, DELETE) define qué acción se quiere ejecutar.
• WordPress enruta la solicitud. El servidor recibe el request y lo pasa al núcleo de WordPress, que lo interpreta como un llamado a la REST API. El sistema de rutas mapea la URL a un endpoint registrado y dispara la función correspondiente (callback).
• Se aplican permisos y contexto. Antes de devolver datos o modificar algo, la API chequea si el usuario está autenticado y si tiene los permisos necesarios. Si el endpoint es público, como los listados de usuarios, puede devolver información sin login, pero con campos limitados.
• La respuesta se arma en JSON. Una vez procesada la lógica del callback (consultar la base de datos, aplicar filtros, formatear datos), WordPress devuelve una respuesta en formato JSON con los datos solicitados y el código de estado HTTP correspondiente.

¿Qué endpoints de WordPress están expuestos por defecto?

Una instalación de WordPress limpia expone los siguientes endpoints sin requerir autenticación en el navegador público. Podés ver el índice completo en cualquier momento visitando https://tusitio.com/wp-json/ — esa información es pública para cualquiera, incluyendo atacantes.

• /wp-json/wp/v2/users: listado de todos los usuarios registrados con nombre, slug, ID, descripción y URLs de avatar. Es el endpoint más crítico porque expone exactamente lo que los atacantes necesitan para ataques de fuerza bruta.
• /wp-json/wp/v2/posts y /wp-json/wp/v2/pages: contenido publicado completo, revisiones, metadatos de estructura y relaciones entre posts. Útil para reconocimiento de la arquitectura del sitio.
• /wp-json/wp/v2/media: listado de todos los archivos subidos al sitio, con URLs directas a cada archivo y datos de tamaño/tipo.
• /wp-json/wp/v2/types y /wp-json/wp/v2/taxonomies: información sobre custom post types, categorías y etiquetas. Mapean la estructura lógica del sitio.
• Endpoints de plugins: cada plugin que usa la REST API agrega los suyos propios. Muchos plugins desarrollados sin consideraciones de seguridad exponen endpoints que devuelven datos sensibles sin verificar permisos adecuados.

La enumeración de usuarios: cómo funciona el ataque

Una petición GET simple a https://tusitio.com/wp-json/wp/v2/users devuelve todos los usuarios registrados con información sensible. El atacante obtiene los nombres de usuario exactos — no tiene que adivinarlos. A partir de ahí, el script de fuerza bruta es automático: arma listas de credenciales combinando esos usuarios con contraseñas comunes y ataca el formulario de login o directamente xmlrpc.php.

El ejemplo más ilustrativo de 2025 fue CVE-2025-24000 en el plugin Post SMTP. Un atacante con una cuenta de suscriptor — el nivel más bajo de acceso — podía escalar a administrador completo simplemente porque el plugin registraba un endpoint en la REST API con 'permission_callback' => '__return_true'. Eso significa que el callback devolvía true para cualquier usuario, sin verificar ninguna capacidad real. El atacante mandaba la petición directamente, sin pasar por la interfaz gráfica del plugin, y podía manipular logs de email para cambiar credenciales de administrador. Según el reporte de Solid WP (agosto de 2025), una porción significativa de las vulnerabilidades de plugins de ese período involucraba exactamente esto: endpoints de REST API con controles de autenticación incompletos.

¿Cuáles son las vulnerabilidades específicas por versión de WordPress?

Las versiones recientes de WordPress tienen vulnerabilidades documentadas en la REST API que afectan directamente cómo está expuesta tu instalación. Si corres WordPress 6.8.x, 6.9.x o 7.0.x, estás en zona de riesgo inmediato.

• WordPress 7.0.x — CVE-2026-63030 y CVE-2026-60137: Vulnerabilidades de ejecución remota de código (RCE) sin autenticación en el endpoint /wp-json/batch/v1. Cualquiera puede enviar peticiones a ese endpoint y ejecutar código arbitrario en el servidor. Parches disponibles; actualizá inmediatamente.
• WordPress 6.9.x — Fallos de validación de permisos: Wordfence reportó en junio de 2026 que varios endpoints de REST API nativos no validaban capacidades de usuario correctamente, permitiendo que usuarios de nivel bajo accedieran a datos que deberían estar restringidos.
• WordPress 6.8.x — Información sensible expuesta: El listado de usuarios está expuesto sin restricción; el endpoint /wp-json/wp/v2/users devuelve información de contacto, descripción y otros datos personales sin autenticación.
• Versiones 6.7 y anteriores — /wp-json/wp/v2/users abierto: Aunque hay parches posteriores, si corres WordPress 6.7 o más viejo, el endpoint de usuarios sigue siendo accesible públicamente por defecto.

Acción inmediata: Visitá Administrador > Actualizaciones en tu WordPress y actualizá a la versión más reciente disponible. Si hay parches de seguridad para tu versión, aplicálos antes que cualquier otra cosa. Después, implementá las restricciones que describe este artículo como segunda capa de defensa.

¿Cómo auditar qué endpoints registra tu instalación?

Antes de aplicar restricciones, necesitás saber qué hay expuesto. Con una simple petición GET podés ver todos los endpoints activos en tu WordPress, incluidos los de plugins instalados. Esto te permite identificar puntos de riesgo específicos de tu configuración.

• Desde el navegador: Visitá https://tusitio.com/wp-json/ y vas a ver el índice JSON completo con todas las rutas registradas. Buscá endpoints que no reconozcas o que parezcan exponer datos sensibles. Puede ser un JSON bastante largo — usá Ctrl+F para buscar palabras clave como «users» o «meta».
• Con curl desde la terminal: Ejecutá curl https://tusitio.com/wp-json/ | jq '.routes | keys' para ver solo las rutas sin el ruido de los detalles de cada una. Rápido para auditorías grandes. Si no tenés jq instalado, podés usar grep para filtrar.
• Con un plugin de auditoría: Plugins como REST API Toolbox o WP REST Cache permiten ver los endpoints registrados desde el admin de WordPress, verificar sus permisos y probar peticiones directas sin salir de la interfaz.

Cuando hagas esa auditoría, buscá endpoints de plugins que no uses activamente. Es común que un plugin viejo registre un endpoint que nadie requiere y que queda expuesto por años. Si ves algo que no entendés, googlealo: el nombre del endpoint + «CVE» te dice si hay vulnerabilidades conocidas. Documentá todo — vas a necesitar esa lista cuando implementes las restricciones.

Cómo restringir la REST API sin romper tu sitio

Acá viene la parte donde más gente se equivoca. Deshabilitar la REST API «completamente» suena bien en el papel, pero rompe el editor Gutenberg, los plugins de formularios, los widgets dinámicos y prácticamente cualquier integración moderna. La opción nuclear no es la solución. Hay tres enfoques que funcionan bien, de menor a mayor agresividad.

Opción 1: bloquear solo el endpoint de usuarios

La medida más quirúrgica que elimina el vector de ataque más común sin tocar nada más. Va en functions.php de tu tema o en un plugin personalizado:

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

Esta solución no rompe nada relevante. Para cubrir también la enumeración vía parámetro de autor (?author=1), agregá una redirección en functions.php que detecte esa intención y devuelva un error 404 o redirija a la portada:

add_action( 'template_redirect', function() {
if ( is_author() ) {
wp_redirect( home_url(), 301 );
exit;
}
} );

Opción 2: requerir autenticación para todas las peticiones anónimas

Más amplia, más completa. Los usuarios no logueados no pueden acceder a ningún endpoint de la REST API, solo los autenticados. Esta opción cierra todos los endpoints públicos de un plumazo, pero exige que cualquier integración externa use autenticación.

add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_not_logged_in',
'Solo los usuarios autenticados pueden acceder a la API REST.',
array( 'status' => 401 )
);
}
return $result;
} );

Ojo: esto puede romper integraciones legítimas que usan la API sin autenticación, como temas que cargan datos de posts vía REST en el frontend anónimo. Antes de activarlo en producción, revisá qué peticiones hace tu sitio a /wp-json/ en el log de accesos del servidor. Si tenés Wordfence, usa el Activity Log para ver todas las peticiones a la API durante una semana normal; eso te dice qué endpoints son realmente públicos.

Opción 3: deshabilitar la REST API (no recomendado)

Todavía hay guías viejas que recomiendan deshabilitar la REST API completamente. La realidad es que eso rompe Gutenberg, el sistema de administración moderno de WordPress, y la mayoría de los plugins que usan bloques dinámicos. Tiene sentido solo en instalaciones muy específicas que corren WordPress como CMS sin acceso remoto. Para casi todos los sitios, no es el camino.

Entendiendo rest_authentication_errors: controlar quién accede a qué

El filtro rest_authentication_errors es el mecanismo central de WordPress para decidir quién puede acceder a la API REST. Te permite granularidad: podés permitir acceso público a ciertos endpoints, requerir autenticación para otros, y bloquear algunos completamente. La clave es entender cómo funciona.

El filtro se ejecuta ANTES de que WordPress procese la petición a cualquier endpoint específico. Si devuelve un WP_Error, WordPress rechaza la petición ahí mismo. Si devuelve null o un valor booleano true, la petición continúa y WordPress chequea después los permission_callback de cada endpoint individual.

Acá hay ejemplos prácticos:

• Bloquear REST API completamente para usuarios no autenticados: add_filter( 'rest_authentication_errors', function( $result ) { if ( ! is_user_logged_in() ) { return new WP_Error( 'rest_forbidden', 'No tienes permiso.', array( 'status' => 403 ) ); } return $result; } );
• Permitir solo ciertas rutas públicamente: add_filter( 'rest_authentication_errors', function( $result ) { $allowed_routes = array( '/wp/v2/posts', '/wp/v2/categories' ); $current_route = $_SERVER['REQUEST_URI'] ?? ''; $is_allowed = false; foreach ( $allowed_routes as $route ) { if ( strpos( $current_route, $route ) !== false ) { $is_allowed = true; break; } } if ( ! $is_allowed && ! is_user_logged_in() ) { return new WP_Error( 'rest_restricted', 'Este endpoint requiere autenticación.', array( 'status' => 401 ) ); } return $result; } );
• Requerir autenticación solo a endpoints de escritura (POST, PUT, DELETE): add_filter( 'rest_authentication_errors', function( $result ) { $method = $_SERVER['REQUEST_METHOD'] ?? 'GET'; if ( in_array( $method, array( 'POST', 'PUT', 'DELETE', 'PATCH' ) ) && ! is_user_logged_in() ) { return new WP_Error( 'rest_write_requires_auth', 'Debes estar autenticado para modificar contenido.', array( 'status' => 401 ) ); } return $result; } );

Regla importante: el filtro rest_authentication_errors es el control de ACCESO GENERAL a la API. Después de que pase ese filtro, cada endpoint tiene su propio permission_callback que valida permisos específicos. Los dos trabajan juntos: el filtro global controla «¿puedo usar la API?», y los callbacks de cada endpoint controlan «¿puedo hacer esto específico?».

Autenticación robusta: Application Passwords vs JWT

Si permitís acceso autenticado a la REST API — lo que casi siempre necesitás para integraciones legítimas — el método de autenticación que elegís importa mucho. WordPress tiene varias opciones con características bien distintas.

Application Passwords (nativo desde WP 5.6)

Los generás desde el perfil del usuario en el admin de WordPress, y los usás en las peticiones con Basic Auth en el header: Authorization: Basic base64(usuario:app-password). Cada integración tiene su propio password, podés revocarlos individualmente sin afectar el login principal del usuario, y quedan registrados con nombre y fecha en el perfil. Si una integración se compromete, revocás ese password específico. No requieren plugins extra.

JSON Web Tokens (JWT)

La opción cuando necesitás tokens con expiración automática o integraciones con apps móviles y SPAs que no quieren guardar credenciales de usuario en el dispositivo. El flujo: el cliente se autentica con usuario y contraseña, recibe un JWT con expiración (típicamente 1 a 4 horas), y lo incluye en cada petición como Authorization: Bearer TOKEN. Cuando expira, usa un refresh token para obtener uno nuevo sin pedir credenciales de vuelta.

Para WordPress, el plugin más mantenido en 2026 es JWT Authentication for WP REST API. Requiere configurar una clave secreta en wp-config.php y modificar el .htaccess para que Apache pase el header de autorización a PHP — ese último paso lo olvida casi todo el mundo y después no entienden por qué los tokens no funcionan.

Comparación de métodos:

Método	Seguridad	Implementación	Expiración	Caso de uso ideal
Application Passwords	Alta	Nativa (sin plugin)	No expira (revocación manual)	Integraciones internas, scripts de servidor, zapier
JWT	Alta	Plugin externo	Sí (configurable, típico 1-4h)	Apps móviles, SPAs, integraciones externas con expiraciones
Nonce	Media	Nativa	24 horas	Solo peticiones desde el navegador logueado
Basic Auth credenciales	Baja	Sin plugin extra	No expira	Solo entornos de desarrollo local, nunca producción
OAuth 2.0	Muy alta	Compleja (plugin + config)	Token de acceso + refresh	Aplicaciones públicas de terceros que acceden en nombre del usuario

Validación de permission_callback: la capa de seguridad que falla

El permission_callback de un endpoint es lo que WordPress consulta para decidir si un usuario logueado específico tiene permiso de ejecutar esa operación. Es donde ocurren la mayoría de los agujeros: un callback mal escrito permite que usuarios sin permiso hagan cosas que no deberían.

WordPress rechaza el registro de endpoints sin un permission_callback desde la versión 5.5, pero la ausencia de callback y un callback que devuelve true no son lo mismo. Ejemplos de lo que NO debes hacer:

• Mal — permitir cualquier usuario: 'permission_callback' => '__return_true' o 'permission_callback' => function() { return true; } — CVE-2025-24000 fue exactamente eso.
• Mal — chequear solo login, no permisos: 'permission_callback' => 'is_user_logged_in' — permite que un suscriptor haga lo que sea si estoy logueado.
• Mal — verificar rol en lugar de capacidad: 'permission_callback' => function() { return current_user_can( 'administrator' ); } — inflexible; no deja que editores accedan aunque deberían poder hacerlo.

Lo que SÍ debes hacer:

• Bien — verificar capacidad específica: 'permission_callback' => function() { return current_user_can( 'manage_options' ); } — solo administradores.
• Bien — verificar múltiples capacidades: 'permission_callback' => function() { return current_user_can( 'edit_posts' ) || current_user_can( 'publish_posts' ); } — autores y superiores.
• Bien — verificar capacidad en un recurso específico: 'permission_callback' => function( $request ) { $post_id = $request['id']; return current_user_can( 'edit_post', $post_id ); } — solo quien puede editar ese post específico.
• Bien — verificación contextual compleja: 'permission_callback' => function( $request ) { return current_user_can( 'read' ) && get_current_user_id() !== 0; } — solo usuarios logueados que tienen capacidad de lectura.

Capacidades estándar de WordPress que usás en callbacks: manage_options (admin), edit_posts (autor+), publish_posts (editor+), read (cualquiera logueado), edit_post (sobre un post específico), delete_post (sobre un post específico). Para endpoints de plugins personalizados, registrá capacidades propias usando add_role() o add_cap().

Rate limiting y WAF: bloqueando el reconocimiento automatizado

Un sitio con la REST API expuesta sin rate limiting puede recibir miles de peticiones por minuto a /wp-json/wp/v2/users sin que pase absolutamente nada. Los bots de escaneo, muchos de ellos distribuidos en redes de IPs, hacen reconocimiento continuo. No les importa si el endpoint devuelve 404 o 200 en la primera prueba.

Las opciones que realmente funcionan en 2026:

• Wordfence Security: tiene reglas de firewall para bloquear /wp-json/* a IPs que superen un umbral de peticiones. La configuración está en el panel de reglas del WAF, y podés combinarlo con bloqueo por país o rangos de IP conocidos como maliciosos. Es el camino más simple si estás dentro de WordPress.
• Rate limiting a nivel servidor (Nginx/Apache): si tu hosting te da acceso a la configuración del servidor, limitá peticiones por IP a nivel del servidor antes de que lleguen a PHP. Más eficiente porque detiene los bots antes de que carguen WordPress. Típicamente: 60 requests por minuto por IP a /wp-json/.
• Cloudflare WAF: si usás Cloudflare como proxy, sus reglas filtran tráfico de scanners conocidos antes de que toquen tu servidor. La versión gratuita incluye protección básica; las reglas avanzadas de WAF requieren el plan Pro ($20+/mes).
• IP whitelisting: si la mayoría de tu tráfico a la API viene de integraciones conocidas (tu ERP, servicio de tracking, herramienta de backup), configurá un whitelist de IPs que pueden acceder. Bloquea todo lo demás. Es el enfoque más restrictivo y más seguro.

¿Vale la pena implementar CAPTCHA en la REST API? Para endpoints de login, sí. Para endpoints de datos, no: los CAPTCHAs rompen las integraciones programáticas que llaman la API desde scripts sin navegador. La solución ahí es autenticación obligatoria, no CAPTCHA.

Validación y sanitización de solicitudes a la REST API

CVE-2025-24000 en Post SMTP es el ejemplo más claro de lo que pasa cuando no validás bien. El plugin asumía que solo el admin iba a llamar ese endpoint porque solo el admin tenía la interfaz gráfica para hacerlo. Cualquier atacante con una cuenta de suscriptor mandó la petición directamente sin pasar por la UI y saltó el control.

La regla más importante: el permission_callback de cualquier endpoint tiene que verificar capacidades explícitamente. No alcanza con verificar que el usuario está logueado. Tiene que verificar que el usuario logueado TIENE EL PERMISO para esa operación específica.

• Validación de parámetros en el schema: Usá el campo args al registrar el endpoint para definir el tipo, formato y función de sanitización de cada parámetro. WordPress tiene funciones como sanitize_text_field(), absint() y callbacks de validación propios.
• Nonces para peticiones desde el navegador: Si tu JavaScript llama a la REST API desde el frontend de WordPress, incluí el nonce (wp_rest) en cada petición. Protege contra CSRF sin afectar las integraciones externas que no tienen acceso a nonces.
• Validación siempre en el servidor: Lo que venga del cliente hay que validarlo de nuevo en el backend. Siempre. Sin excepción. La validación del navegador es solo UX, no seguridad.

Monitoreo: detectar intentos maliciosos contra la API

Los logs de WordPress por defecto no registran accesos a la REST API de forma granular. Después de implementar las restricciones, necesitás saber si alguien intenta saltárselas, porque sin monitoreo las restricciones son ciegas.

• Wordfence Activity Log: Registra todas las peticiones a /wp-json/, intentos de autenticación fallidos y bloqueos por IP. La versión gratuita es suficiente para la mayoría de los sitios y genera alertas cuando ve patrones sospechosos.
• Plugin de auditoría: Plugins como REST API Toolbox permiten ver qué endpoints se están usando, desde dónde, y con qué frecuencia. Útil para identificar integraciones nuevas o inesperadas.
• Logs de acceso del servidor: Buscá picos de peticiones GET a /wp-json/wp/v2/users. Un bot de escaneo típico hace decenas de peticiones en pocos segundos desde la misma IP o desde un rango reducido de IPs. Si ves eso, la IP merece estar bloqueada.

Una alerta concreta que vale configurar en Wordfence: notificaciones cuando un endpoint específico supera X peticiones por hora desde la misma IP. No es configuración avanzada — está en el panel de reglas — y captura el grueso de los escaneos automatizados.

Checklist de implementación para proteger tu REST API

• Actualizar WordPress. Si corres WordPress 6.8.x, 6.9.x o 7.0.x, actualizá inmediatamente a la versión parche disponible. Las CVE-2026-63030 y CVE-2026-60137 son críticas.
• Auditar endpoints activos. Visitá https://tusitio.com/wp-json/ y revisá qué endpoints tenés expuestos. Identificá cuáles son de plugins que no usás o que no deberían ser públicos.
• Eliminar el endpoint de usuarios. Agregá el filtro rest_endpoints en functions.php para unset /wp/v2/users. Es la medida más urgente.
• Revisar plugins que registran endpoints. Para cada plugin que ves que agrega endpoints, buscá en Google si hay CVEs o problemas de seguridad conocidos. Actualiza o desactiva si es necesario.
• Implementar autenticación para integraciones externas. Si usás Zapier, Make.com, o scripts que llaman tu API, configurá Application Passwords. Revoca las que no uses más.
• Activar rate limiting. Ya sea con Wordfence, a nivel servidor, o con Cloudflare, limitá la velocidad de peticiones a la API. Mínimo 60 requests/minuto por IP.
• Instalar y configurar Wordfence. La versión gratuita ya bloquea escaneos comunes. Activa las reglas de WAF para /wp-json/.
• Implementar rest_authentication_errors. Agregá el filtro para requerir autenticación en los endpoints que sea necesario. Testea qué integraciones se rompen.
• Revisar permission_callback en endpoints propios. Si desarrollaste endpoints personalizados, verificá que cada uno tiene un permission_callback que valida capacidades específicas, no solo __return_true.
• Configurar Activity Log. En Wordfence o en el plugin que uses, configurá alertas para detectar patrones sospechosos en la API.
• Probar las restricciones. Con curl o Postman, verificá que los endpoints públicos devuelven error 401 cuando intentás acceder sin autenticación. Probá que los endpoints autenticados funcionan con las credenciales correctas.
• Documentar los cambios. Mantené una nota sobre qué endpoints restringiste, qué plugins requieren acceso autenticado, y cuáles son las credenciales de cada integración (en un gestor de secretos, no en un archivo de texto).

Errores comunes que dejan la REST API vulnerable

• No actualizar WordPress. Un sitio que corre WordPress 6.9 sin parches expone vulnerabilidades documentadas. Los exploits públicos existen; es solo cuestión de tiempo antes de que te toquen.
• Asumir que «nadie va a saber que existe ese endpoint». Los bots escanean /wp-json/ 24/7. Lo que está registrado, está expuesto. No hay «seguridad por oscuridad» acá.
• Aplicar solo restricciones a nivel UI. Si tu plugin tiene interfaz gráfica que verifica permisos, pero el endpoint REST no tiene permission_callback, alguien que llame la API directamente salta la UI. La validación tiene que estar en el servidor, no en el navegador.
• Bloquear la REST API completamente sin verificar qué se rompe. Gutenberg usa la API. Algunos temas la usan para cargar posts dinámicamente. Si bloqueás todo sin auditar primero, tu sitio se cae.
• No monitorear después de implementar restricciones. Podés haber hecho bien el trabajo, pero si no chequeás los logs, nunca vas a saber si alguien está intentando saltarse las defensas que pusiste.

¿Qué sigue? — Estrategia de defensa a largo plazo

Proteger la REST API no es una tarea puntual — es parte de la rutina de mantenimiento de tu sitio. Las vulnerabilidades nuevas aparecen cada semana. Los patrones de ataque evolucionan. Acá hay lo que deberías estar haciendo regularmente.

• Revisar logs de API cada mes. Chequeá Wordfence Activity Log o los logs de tu servidor. Buscá patrones anómalos: peticiones repetidas, IPs desconocidas, intentos a endpoints que deberían estar bloqueados.
• Auditar endpoints de plugins cada trimestre. Cuando instales un plugin nuevo, verificá si registra endpoints. Cuando desinstales uno, chequeá que haya limpiado sus rutas. Los plugins muertos dejan endpoints vivos.
• Actualizar WordPress el mismo día que sale un parche. No es «cuando encuentres tiempo». Los exploits se publican horas después del parche. Si esperas una semana, ya hay bots atacando.
• Revisar Application Passwords cada 6 meses. ¿Hay passwords que ya no usás? Eliminá esos. ¿Hay integraciones que debería estar monitoreando? Anotálas.
• Medir y ajustar rate limits según tu tráfico real. Si movés un sitio a un servidor más potente o tu audiencia crece, tus límites de rate limiting pueden ser demasiado restrictivos. Revisá cada 2-3 meses.

La protección de la REST API es una capas. Una sola no alcanza. Necesitás todas: actualizaciones, restricciones de endpoints, autenticación robusta, rate limiting, validación en cada callback, y monitoreo constante. Si descuidás una, los atacantes van a encontrar esa grieta.