Application Passwords en WordPress: ventajas, riesgos y cómo crearlas paso a paso

Si tienes WordPress y nunca has tocado las Application Passwords, te estás perdiendo una de las herramientas más útiles del CMS desde 2020 — pero también una puerta lateral que el 80 % de los administradores tienen abierta sin saberlo.

Vamos a desmontarlas: para qué sirven, cuándo te salvan, cuándo te exponen, y cómo crear una sin meterte en un lío.

Qué son y por qué se inventaron

Hasta WordPress 5.6 (diciembre 2020), si querías que un script externo o una herramienta como Make, Zapier, MainWP o un crawler propio leyera datos de tu WP vía REST API (la puerta técnica por la que apps externas leen y escriben datos en WordPress sin pasar por el panel), tenías dos opciones malas:

1. Meter tu password real de administrador en el script → cualquier persona con acceso al código tiene tu cuenta entera
2. Plugins de autenticación JWT (otro sistema de tokens, más complejo de montar) que añaden complejidad + dependencia externa

WordPress core añadió Application Passwords: tokens generados por el propio WordPress, de 24 caracteres, vinculados a un usuario y revocables individualmente. Apps externas autentican vía HTTP Basic Auth (la forma más sencilla de mandar usuario + clave en cada petición) con usuario:token contra /wp-json/.

Es lo más parecido a un “OAuth ligero” (OAuth es el estándar de la industria donde la app pide permisos concretos al usuario) sin necesidad de plugins. Documentación oficial: WordPress.org · Application Passwords.

Ventajas reales

1. No expones tu password humano

El token NO es tu password de login. Si el script se compromete, revocas ese token y tu password sigue intacto.

2. Revocación granular

Lista todos los app passwords activos en tu perfil. Borras el que quieras sin afectar al resto. Mucho mejor que la opción “cambiar el password global” que te obliga a actualizar 10 sitios donde lo tienes metido.

3. Auditable: nombre + fecha de uso

Cada token lleva un nombre identificativo (lo eliges tú al crearlo) + WordPress registra la fecha de último uso. De un vistazo ves “este lo creé hace 6 meses para Make y no se usa desde marzo → fuera”.

4. No rompe tu 2FA

Si tienes plugins tipo Wordfence 2FA o Two Factor, tu login humano sigue protegido. El token salta el 2FA solo en REST API — porque el 2FA está pensado para humanos, no para integraciones automatizadas.

5. Funciona out-of-the-box

Cero plugins, cero configuración de servidor. Lo activas en tu perfil y ya tienes endpoint REST funcionando con auth correcta.

6. Compatibilidad universal

Cualquier cliente HTTP que soporte Basic Auth puede consumir tu API. Esto incluye Make, Zapier, n8n, curl, Postman, Python requests, plugins WordPress que necesiten conectar a otra instalación (MainWP), etc.

Desventajas y riesgos reales

Ahora la otra cara — la que casi ningún tutorial te cuenta:

1. Permisos al nivel del usuario, no granular

Un app password tiene exactamente los mismos permisos que el usuario que lo crea. Si lo creas con tu cuenta admin, ese token puede:

• Crear/editar/borrar cualquier post
• Subir media
• Cambiar usuarios y roles
• Instalar plugins y temas (= ejecutar código en tu servidor)
• Acceder a tu información de perfil

No hay scopes tipo OAuth (permisos finos del tipo “solo lectura de posts” o “solo borrar comentarios”). Es todo o nada.

2. Endpoint /wp-json/users/me revela usernames

Una vez tienes un app password, GET /wp-json/wp/v2/users/me te da el username. Y si conoces el username + el token, tienes la cuenta. Nunca subas tokens a un repo público ni los pegues en logs sin redactar.

3. El propio /wp-json/users lista usernames sin auth

Por defecto WordPress expone /wp-json/wp/v2/users sin autenticación → cualquier bot puede enumerar tus usernames. Es la primera fase de un ataque de fuerza bruta contra Application Passwords.

4. No tienen expiración por defecto

Una vez creas un token, vive para siempre hasta que tú lo revoques. Si olvidas que lo tienes activo y la app/servicio donde lo usabas se cierra, queda huérfano + atacable.

5. Ataques de fuerza bruta vía /wp-json/

Tokens son strings aleatorios de 24 chars, ya — pero los atacantes no van letra a letra. Buscan fugas en GitHub público, paste sites, dumps, y cuando encuentran uno lo prueban directamente. Sin rate limiting en /wp-json/, prueban miles por hora.

6. Vulnerable a man-in-the-middle si no usas HTTPS

Basic Auth manda el token en cada request, codificado en Base64 pero NO encriptado (Base64 es codificación reversible que cualquiera puede deshacer; no es cifrado real). Sin HTTPS, cualquier red intermedia (WiFi público, ISP malicioso, proxy mal configurado) puede capturarlo.

7. Sin avisos cuando algo va mal

Si te roban un app password y empiezan a hacer requests raros, WordPress core no te avisa por email ni en el panel. Necesitas plugin de auditoría (Wordfence, WP Activity Log) o revisar logs de servidor manual.

Cuándo SÍ usarlas

Cuándo NO usarlas

• Como atajo “para no escribir mi password 5 veces” → para humanos usa gestor de contraseñas + 2FA, no app passwords
• Para apps de terceros que no auditas → si la app cierra o se compromete, ya tienen acceso permanente hasta que lo notes
• Sin HTTPS en el servidor → cancelar antes de generar nada
• Si tu sitio NO necesita REST API encendido → mejor desactivar /wp-json/ entero (plugins tipo “Disable REST API” o reglas WAF)
• Como ÚNICA capa de seguridad → siempre va junto con rate limit + 2FA en login + WAF

Cómo sacar una Application Password (paso a paso)

Esto es lo que mucha gente pregunta — el flujo real, sin captura por captura:

Paso 1: Verifica que las tienes activas

Login → Usuarios → Tu perfil → scroll hasta abajo. Si ves la sección “Application Passwords” está activo. Si NO lo ves:

• WordPress < 5.6 → actualiza el core
• Plugin de seguridad puede haberlas desactivado (Wordfence, iThemes Security) → activa la opción en sus settings
• Algunas instalaciones managed (WP Engine, Kinsta) las pueden tener bloqueadas → contacta soporte

Paso 2: Asigna un nombre identificativo

En el campo “New Application Password Name” pon algo que reconozcas dentro de 6 meses:

• ✅ Bien: Make - sync posts de tienda - 2026-05
• ✅ Bien: MainWP dashboard finca
• ❌ Mal: test, prueba, nuevo

Este nombre te servirá para identificar qué token revocar el día que lo pierdas o quieras limpiar.

Paso 3: Click en “Add New Application Password”

WordPress genera un token de 24 caracteres con formato XXXX XXXX XXXX XXXX XXXX XXXX (con espacios cada 4 chars).

Paso 4: Copia el token YA — solo aparece una vez

⚠️ Importante: el token completo aparece una sola vez en pantalla. Si cierras la pestaña sin copiarlo, tienes que revocarlo y generar otro.

Cópialo a tu gestor de contraseñas (Bitwarden, 1Password, KeePass) con etiqueta clara: WP App Password · midominio.com · nombre que pusiste.

Si la app a la que lo vas a meter te lo pide en formato sin espacios, los espacios son cosméticos. WordPress acepta ambos formatos al autenticar.

Paso 5: Configura la app receptora

En Make/Zapier/MainWP/tu script:

• URL base: https://tudominio.com/wp-json/wp/v2/
• Tipo de auth: HTTP Basic Auth
• Username: tu nombre de usuario WordPress (el del login, no el email)
• Password: el token que acabas de copiar (con o sin espacios)

Si la app habla de “Application Password” o “REST API token”, es lo mismo.

Paso 6: Verifica con un request de prueba

Antes de meterlo en producción, prueba:

curl -u "tu_usuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://tudominio.com/wp-json/wp/v2/users/me

Si te devuelve JSON con tu info de usuario → funciona. Si te devuelve 401 Unauthorized → revisa username + token + que tu hosting no esté bloqueando Authorization headers (algunos sí lo hacen).

Paso 7: Apunta la fecha en un calendario

Pon una alerta a 90 días vista: “revisar app passwords WP de midominio.com”. Revocas los que no se hayan usado, renuevas los que sí.

Cómo blindar las Application Passwords

Si vas a usarlas en serio, mínimos:

1. Crear un usuario dedicado por integración, con rol mínimo necesario (Editor o Author, no Administrator). El token hereda permisos del usuario.
2. HTTPS obligatorio — sin esto no las uses
3. Rate limit en /wp-json/ vía WAF (Web Application Firewall — filtro inteligente que decide qué peticiones dejar pasar) — Cloudflare gratis, ModSecurity, o SeoNova WPO Toolkit. Sin esto, los bots prueban tokens fugados a saco
4. Bloquear /wp-json/wp/v2/users sin auth para no exponer usernames. Cloudflare WAF rule o .htaccess
5. Plugin de auditoría (Wordfence, WP Activity Log) para alertas cuando hay actividad rara
6. Rotación cada 90 días o cuando un servicio cambie de manos
7. Nunca hardcodear en repos públicos — usa .env + secret manager

Conexión con crawl budget: los bots que prueban tokens fugados machacan /wp-json/ con cientos de requests por minuto. Es parte del 49,6 % de tráfico bot del Imperva Bad Bot Report. Bloquearlos protege también tu indexación en Google.

Cierre

Application Passwords son una herramienta brutal para automatizar WordPress sin comprometer tu cuenta humana. Bien usadas, te permiten conectar Make, Zapier, MainWP, scripts y cualquier integración REST con cero fricción.

Mal usadas — sin HTTPS, sin rate limiting, sin rotación, sin scope mínimo en el usuario — son una puerta lateral con permisos de admin que vive para siempre hasta que te roben el token.

Sigue los 7 pasos del paso a paso + los 7 puntos de blindaje, y te quedas en el lado que aprovecha la ventaja sin pagar el coste.

Si quieres dejar tu /wp-json/ protegido contra fuerza bruta + bots + scrapers sin tocar plugins, WPO Toolkit de SeoNova incluye un módulo específico para esto. Bloquea la actividad maliciosa antes de que toque tu PHP — y de paso recupera crawl budget para Google y Bing.

¿Dudas? [email protected]. Si tu pregunta es buena, acaba en el blog (sin tu nombre).

— El equipo de SeoNova