Desde la versión 5.6, cada usuario de WordPress tiene en su perfil una sección llamada Contraseñas de aplicación. Muy poca gente la mira, y eso es justamente lo que la hace interesante, para bien y para mal.
Qué son, en simple
Son contraseñas especiales, generadas por WordPress, que sirven para que otra aplicación se conecte a tu sitio en tu nombre: la app móvil, un servicio de automatización como Zapier o Make, un panel para administrar varios sitios, un script tuyo que publica entradas o un asistente de IA conectado a WordPress.
Sus ventajas frente a usar tu contraseña real:
- No sirven para entrar al escritorio. Solo funcionan con la API REST y XML-RPC.
- Se pueden revocar una por una, sin cambiar tu contraseña principal.
- WordPress anota cuándo y desde qué IP se usó cada una por última vez.
Solo funcionan si tu sitio usa HTTPS. Si no ves la sección en tu perfil, puede ser por eso o porque un plugin de seguridad la desactivó.
El lado oscuro: una puerta trasera perfecta
Imagina que alguien consigue entrar como administrador. Tú lo detectas, cambias la contraseña y respiras tranquila. Pero si el intruso alcanzó a crear una contraseña de aplicación, sigue teniendo acceso completo por la API, y cambiar tu contraseña principal no la anula.
Además, algunos plugins de doble factor (2FA) no las cubren: protegen el formulario de inicio de sesión, pero no las peticiones a la API.
Después de cualquier incidente de seguridad, revisa las contraseñas de aplicación de todos los administradores y revoca las que no reconozcas. Es un paso que casi todas las guías de limpieza olvidan.
Cómo revisarlas
Desde el escritorio: Usuarios → Perfil de cada administrador, al final de la página. Verás el nombre que se le dio, la fecha de creación, el último uso y la última IP.
Con WP-CLI, para todos los administradores de una vez:
for id in $(wp user list --role=administrator --field=ID); do
echo "== Usuario $id"
wp user application-password list "$id" --fields=uuid,name,created,last_used,last_ip
done
# Revocar una concreta
wp user application-password delete 1 <uuid>Cómo usarlas bien (ejemplo práctico)
Crea una por cada aplicación, con un nombre claro («Zapier tienda», «Script respaldos»). Para probar que funciona, desde una terminal:
curl --user "tu_usuario:abcd EFGH ijkl MNOP qrst UVWX" https://tudominio.cl/wp-json/wp/v2/users/meSi responde con tus datos de usuario, está todo bien. Si responde 401 y la contraseña es correcta, tu servidor puede estar descartando la cabecera de autenticación. En servidores con Apache o LiteSpeed, agrega esta línea al principio del .htaccess:
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1Buena práctica: crea un usuario aparte con el rol mínimo necesario (por ejemplo, Editor) para cada integración, y genera la contraseña de aplicación en ese usuario, no en tu administrador.
Limitarlas o apagarlas
Si nadie en tu sitio las usa, lo más seguro es desactivarlas. Si las usas, puedes permitirlas solo a ciertos roles. Las dos opciones en un mu-plugin, wp-content/mu-plugins/cwp-contrasenas-app.php:
<?php
/**
* Plugin Name: Contraseñas de aplicación bajo control (Curso WordPress)
*/
// OPCIÓN A: apagarlas en todo el sitio (descomenta la línea).
// add_filter( 'wp_is_application_passwords_available', '__return_false' );
// OPCIÓN B: permitirlas solo a editores y autores, nunca a administradores.
add_filter( 'wp_is_application_passwords_available_for_user', function ( $disponible, $usuario ) {
if ( user_can( $usuario, 'manage_options' ) ) {
return false;
}
$roles_permitidos = array( 'editor', 'author' );
return (bool) array_intersect( $roles_permitidos, (array) $usuario->roles );
}, 10, 2 );La opción B es un buen equilibrio: tus integraciones funcionan con usuarios de permisos limitados y, si alguien roba una de esas contraseñas, no podrá instalar plugins ni crear administradores.
¿Encontraste una contraseña de aplicación que no reconoces? Cuéntanos en el foro su nombre y cuándo se creó (sin compartir la contraseña) y te ayudamos a ver de dónde salió.
