Todos conocemos el 404, el 403, incluso el 402, y también las contraseñas de WordPress y el login de toda la vida. Pero hay una funcionalidad que lleva en WordPress desde la versión 5.6 (diciembre de 2020) y que la mayoría de usuarios ni sabe que existe, me refiero a las contraseñas de aplicación (application passwords).

Si te dedicas al desarrollo con WordPress o gestionas webs de clientes las contraseñas de aplicación te van a interesar. Y si no las usas para nada también te interesa saber que están ahí activadas por defecto, con algunas implicaciones de seguridad que merece la pena conocer.

Esta guía cubre todo lo que necesitas saber sobre las contraseñas de aplicación de WordPress: qué son, cómo funcionan, para qué sirven, cómo crearlas (desde el panel, con PHP y con WP-CLI) y, sobre todo, los riesgos que tienen y cómo controlarlos.

Índice de contenidos

Qué son las contraseñas de aplicación

Una contraseña de aplicación es una credencial que WordPress genera para que aplicaciones, scripts o servicios externos se identifique a través de la REST API (y también contra XML-RPC, aunque no debería) sin necesitar la contraseña real del usuario.

Lo más relevante:

Son contraseñas de 24 caracteres (letras y números) que WordPress muestra agrupadas en bloques de 4 para que sean más legibles. Los espacios se ignoran al validarlas.
Están vinculadas a un usuario concreto y heredan sus permisos. Si la crea un administrador la aplicación tendrá acceso de administrador.
No sirven para entrar en wp-admin, solo funcionan para peticiones a la API.
Se almacenan como hash en la tabla usermeta, no en texto plano.
Solo se muestran una vez, en el momento de crearlas. Si la pierdes toca generar una nueva.
Puedes crear varias para un mismo usuario, una por cada aplicación que necesite acceso.
Se pueden anular individualmente.
Por defecto solo funcionan con HTTPS.

Vienen incluidas en el núcleo de WordPress, no hace falta instalar nada. Si tu sitio funciona con WordPress 5.6 o superior (es decir, prácticamente cualquier instalación actualizada) ya las tienes disponibles.

Cómo funcionan por dentro

Cuando una aplicación hace una petición a la REST API envía las credenciales mediante HTTP Basic Authentication (RFC 7617). La cabecera Authorization lleva el nombre de usuario y la contraseña de aplicación codificados en Base64.

WordPress recibe esa petición, detecta que viene por una ruta de API y comprueba la contraseña contra los hashes almacenados en usermeta. Si coincide verifica la petición con los permisos del usuario asociado.

Un detalle importante a tener en cuenta es que WordPress solo intenta validar contraseñas de aplicación en contextos que considera «de aplicación«, que por defecto son la REST API y XML-RPC. Si una petición llega por otra vía no se procesan. Los desarrolladores pueden ampliar esto con el filtro application_password_is_api_request.

¿Sirven para algo?

Pues sí, de hecho si eres desarrollador o trabajas en una agencia que gestiona varias webs WordPress aquí es donde las contraseñas de aplicación empiezan a tener sentido.

Despliegues y automatización (CI/CD)

Scripts que publican contenido, limpian transients o gestionan plugins tras un despliegue se pueden identificar contra la REST API con una contraseña de aplicación en lugar de forzar en el código credenciales de usuario. Si trabajas con flujos de integración y despliegue continuo esto simplifica mucho la gestión de accesos.

Paneles de gestión para agencias

Si administras decenas de sitios de clientes puedes construir un panel propio que consulte el estado de cada web, lance actualizaciones o gestione usuarios en bloque, todo identificado con contraseñas de aplicación específicas para cada sitio.

Sincronización entre sitios

Mover contenido entre un entorno de staging y producción o sincronizar posts entre varios WordPress de una red, sin compartir contraseñas de usuario reales.

WordPress headless

Cuando usas WordPress como backend y el frontend va con Next.js, Nuxt u otro framework, las peticiones identificadas a la REST API necesitan credenciales. Las contraseñas de aplicación son la forma nativa de resolverlo.

Integraciones WooCommerce a medida

Sincronizar inventario con un ERP propio, gestionar pedidos desde herramientas internas o conectar sistemas de facturación. Cada integración puede tener su propia contraseña con acceso limitado al perfil necesario.

Scripts de mantenimiento

Limpieza de revisiones, comprobación de salud del sitio, informes periódicos automatizados, todo lo que un script necesita hacer de forma programada contra la API.

Apps móviles propias

Si desarrollas una app para que los clientes de una agencia publiquen contenido o gestionen sus webs sin entrar en wp-admin, la identificación con contraseñas de aplicación es la solución nativa.

Testing automatizado

Son muy prácticas para pruebas contra la REST API en entornos de desarrollo, sin tener que arriesgar con credenciales reales. También funcionan para conectar servicios externos como Zapier o Make, o para hacer pruebas con Postman, pero esos son casos más puntuales.

La ventaja común a todos estos escenarios es triple:

No compartes tu contraseña real
Puedes anular el acceso de un script concreto sin tocar nada más
La automatización no se bloquea por el 2FA

Cómo crear y gestionar contraseñas de aplicación

Hay tres formas, desde el panel de administración, con PHP y con WP-CLI.

Desde el perfil de usuario (wp-admin)

Es la forma más directa y la que usará cualquier usuario que necesite crear una.

Entra en Usuarios → Perfil (o edita el perfil de otro usuario si eres administrador).
Baja hasta la sección Contraseñas de aplicación.
Escribe un nombre descriptivo para identificar la aplicación (por ejemplo: «Script para producción», «Panel de agencia», «Aplicación móvil»).
Pulsa en «Añadir nueva contraseña de aplicación»
Copia la contraseña inmediatamente porque no se vuelve a mostrar.

En esa misma sección puedes ver las contraseñas creadas, cuándo se usaron por última vez, desde qué IP y anularlas individualmente.

Con PHP

Desde WordPress 5.6 tienes la clase WP_Application_Passwords para gestionar contraseñas de aplicación por código. Esto es lo que usarías en un plugin o en un mu-plugin para automatizar la creación.

// Crear una contraseña de aplicación para el usuario con ID 1
$user_id = 1;
$app_name = 'Mi script de despliegue';

$result = WP_Application_Passwords::create_new_application_password(
    $user_id,
    array( 'name' => $app_name )
);

if ( is_wp_error( $result ) ) {
    // Error al crear la contraseña
    error_log( $result->get_error_message() );
} else {
    // $result[0] = la contraseña en texto plano (solo ahora)
    // $result[1] = array con los datos almacenados (uuid, name, etc.)
    $password = $result[0];
    $app_data = $result[1];
    
    // Guarda $password de forma segura, no se puede recuperar después
}

Para listar las contraseñas de un usuario:

// Obtener todas las contraseñas de aplicación de un usuario
$passwords = WP_Application_Passwords::get_user_application_passwords( $user_id );

foreach ( $passwords as $app_pass ) {
    // $app_pass['name'] = nombre de la aplicación
    // $app_pass['uuid'] = identificador único
    // $app_pass['created'] = timestamp de creación
    // $app_pass['last_used'] = timestamp del último uso
    // $app_pass['last_ip'] = última IP que la usó
}

Para anular una contraseña concreta por su UUID:

// Anular una contraseña de aplicación específica
$uuid = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx';
$deleted = WP_Application_Passwords::delete_application_password( $user_id, $uuid );

if ( is_wp_error( $deleted ) ) {
    error_log( 'No se pudo anular: ' . $deleted->get_error_message() );
}

Y para anular todas las de un usuario de golpe:

// Anular todas las contraseñas de aplicación de un usuario
WP_Application_Passwords::delete_all_application_passwords( $user_id );

Con WP-CLI

Si gestionas el servidor por SSH, WP-CLI te permite hacer lo mismo desde el terminal:

# Crear una contraseña para el usuario con ID 1
wp user application-password create 1 "Script de despliegue"

# Crear y mostrar solo la contraseña (útil para scripts)
wp user application-password create 1 "Script CI" --porcelain

# Listar contraseñas con detalle
wp user application-password list 1 --fields=uuid,name,created,last_used,last_ip

# Anular una contraseña por UUID
wp user application-password delete 1 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

La documentación completa está en la referencia de WP-CLI.

Ejemplo práctico: autenticación con la REST API

Una vez que tienes una contraseña de aplicación usarla es sencillo. Las peticiones van con HTTP Basic Auth, pasando el nombre de usuario y la contraseña de aplicación.

Leer datos del usuario autenticado

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://tusitio.com/wp-json/wp/v2/users/me

Crear una entrada nueva

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"title":"Entrada de prueba","content":"Creada desde la API","status":"draft"}' \
  https://tusitio.com/wp-json/wp/v2/posts

Listar los ajustes del sitio

curl --user "tuusuario:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://tusitio.com/wp-json/wp/v2/settings

Los espacios en la contraseña se pueden incluir o no, WordPress los elimina antes de validar. Si usas la contraseña en un script, es más práctico quitarlos.

Lo mismo con PHP

Si prefieres hacerlo desde PHP con la HTTP API de WordPress (por ejemplo, desde otro WordPress o desde un script):

// Petición identificada a la REST API de otro sitio WordPress
$response = wp_remote_get(
    'https://otrowp.com/wp-json/wp/v2/posts',
    array(
        'headers' => array(
            'Authorization' => 'Basic ' . base64_encode( 'usuario:xxxxxxxxxxxxxxxxxxxxxx' ),
        ),
        'timeout' => 10,
    )
);

if ( ! is_wp_error( $response ) && 200 === wp_remote_retrieve_response_code( $response ) ) {
    $posts = json_decode( wp_remote_retrieve_body( $response ), true );
    // Procesar los posts
}

Riesgos de usar las contraseñas de aplicación de WordPress

Las contraseñas de aplicación son una buena solución para la identificación programática, pero tienen algunos puntos chungos que conviene que tengas claros.

Se saltan el 2FA, los CAPTCHA y los límites de login

Este es el más gordo. Cuando WordPress detecta que una petición viene por la API con una contraseña de aplicación la identifica directamente, la da por buena. No pide doble verificación, no muestra CAPTCHA y no aplica los límites de intentos de acceso que tengas configurados. Es lógico, porque una máquina no puede resolver un CAPTCHA, pero significa que si alguien consigue una contraseña de aplicación tiene acceso directo y no le afecta ninguna medida de seguridad para el inicio de sesión.

Todos los usuarios pueden crearlas

Por defecto, cualquier usuario registrado puede generar contraseñas de aplicación desde su perfil, incluidos los suscriptores. En la mayoría de los sitios los suscriptores no necesitan acceso a la API, así que dejarles crear credenciales persistentes para ello es dejar abierta una posible vía de ataque innecesaria.

No caducan

Una contraseña de aplicación es válida hasta que alguien la revoque manualmente. No hay caducidad automática ni recordatorios de renovación. Si creas una, la usas tres meses para un proyecto y luego te olvidas de ella, seguirá funcionando indefinidamente.

No tienen permisos selectivos

La contraseña hereda los permisos completos del usuario que la crea. No puedes limitar una contraseña de aplicación para que solo pueda leer entradas pero no crearlas, o para que solo acceda a ciertos endpoints. Si la crea un administrador tiene acceso de administrador a toda la API.

Fuerza bruta contra la API

Aunque las contraseñas son largas (24 caracteres alfanuméricos) la protección contra fuerza bruta depende de lo que tengas configurado a nivel de servidor o de plugin de seguridad. WordPress por defecto no limita los intentos de identificación en la REST API de la misma forma que limita los intentos de login en wp-login.php.

Funcionan también sobre XML-RPC

Las contraseñas de aplicación no solo autentican peticiones a la REST API, también sirven para XML-RPC. Y XML-RPC es un protocolo que arrastra problemas de seguridad desde hace años: permite ataques de fuerza bruta amplificados (con system.multicall puedes probar cientos de contraseñas en una sola petición), es vector habitual de ataques DDoS y ofrece una superficie de ataque que la REST API ya cubre con más control.

La mayoría de los sitios WordPress actuales no necesitan XML-RPC para nada. Tenía sentido cuando se usaban clientes de escritorio como Windows Live Writer o la app móvil antigua, pero hoy la REST API lo sustituye en todos los escenarios. Sin embargo, XML-RPC sigue activado por defecto en WordPress, y las contraseñas de aplicación le dan una vía de identificación adicional.

Si no usas XML-RPC (y casi seguro que no lo usas) lo más sensato es desactivarlo. Plugins como Vigilant lo bloquean por defecto nada más activarlo, sin que tengas que configurar nada. También puedes hacerlo manualmente añadiendo add_filter( 'xmlrpc_enabled', '__return_false' ); a un mu-plugin.

Entonces, ¿son un riesgo real?

Depende del contexto. Algunos plugins de seguridad como Shield Security argumentan que si nunca creas una contraseña de aplicación el sistema no intenta validar por esa vía, así que el riesgo sería mínimo. Y tienen razón en parte, porque si no las usas no añaden posibilidad de ataque.

Pero el problema es que están activadas por defecto para todos los usuarios, y no todo el mundo sabe qué son ni qué implicaciones tiene crearlas. Para un sitio con pocos usuarios de confianza no supone un drama, para uno con registro abierto y cientos de suscriptores es un punto que vale la pena controlar.

Buenas prácticas de seguridad

Si vas a usar contraseñas de aplicación sigue estas pautas:

Una contraseña por aplicación: Así puedes anular el acceso de una integración sin afectar a las demás.
Mínimo privilegio: No crees la contraseña desde una cuenta de administrador si la aplicación solo necesita leer o editar posts. Usa un usuario con perfil de editor o autor.
Revisa periódicamente: Comprueba las contraseñas activas de cada usuario y revoca las que ya no se usen.
Guarda las contraseñas de forma segura: Trátalas como cualquier otra credencial sensible: gestor de contraseñas, variables de entorno, nunca en el código fuente.
Monitoriza el uso: WordPress registra la fecha y la IP del último uso de cada contraseña. Si ves algo raro, revoca.
Limita quién puede crearlas: Si tus usuarios no necesitan acceso a la API, desactívalas para sus perfiles.

Cómo desactivar o controlar las contraseñas de aplicación

Si has decidido que no las necesitas, o que quieres limitar quién puede usarlas, tienes varias opciones.

Desactivarlas para todo el sitio (PHP)

Con una línea en un mu-plugin o en functions.php puedes desactivar la funcionalidad por completo:

// Desactivar las contraseñas de aplicación en todo el sitio
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Esto hace que desaparezca la sección del perfil de usuario y que las contraseñas existentes dejen de funcionar.

Limitarlas por perfil de usuario (PHP)

Si quieres que solo los administradores puedan crearlas y usarlas, puedes filtrar por usuario:

// Solo permitir contraseñas de aplicación a administradores
add_filter( 'wp_is_application_passwords_available_for_user', 'ayudawp_limitar_app_passwords', 10, 2 );
function ayudawp_limitar_app_passwords( $available, $user ) {
    // Solo administradores pueden crear y usar contraseñas de aplicación
    if ( ! user_can( $user, 'manage_options' ) ) {
        return false;
    }
    return $available;
}

Esto es lo más recomendable en la mayoría de los sitios: mantener la funcionalidad disponible para quienes realmente la necesitan y cerrarla para el resto.

Forzar su funcionamiento sin HTTPS (solo para desarrollo)

Por defecto, las contraseñas de aplicación solo se procesan en conexiones HTTPS. Si estás en un entorno de desarrollo local sin certificado SSL, puedes forzar su disponibilidad:

// Permitir contraseñas de aplicación sin HTTPS (solo en local)
add_filter( 'wp_is_application_passwords_available', '__return_true' );

No uses esto en producción. Las credenciales viajan en texto plano por HTTP y cualquiera que intercepte el tráfico puede leerlas.

Con plugins

Si prefieres no tocar código hay plugins que te lo resuelven con un clic. El plugin Vigilant (gratuito) incluye la opción de desactivar las contraseñas de aplicación desde su módulo de seguridad en el acceso. También existe Disable Application Passwords que hace solo eso, es una sola función, lo activas y listo. Otros plugins como WP Cerber o Advanced Access Manager ofrecen control más detallado por perfiles si es algo que necesitas de manera específica.

Filtros y ganchos disponibles para desarrolladores

Si estás desarrollando un plugin que interactúa con las contraseñas de aplicación estos son los filtros que te interesan:

wp_is_application_passwords_available: Controla si la funcionalidad está disponible en el sitio (true/false).
wp_is_application_passwords_available_for_user: Controla si un usuario concreto puede crear y usar contraseñas de aplicación.
application_password_is_api_request: Permite marcar peticiones que no sean REST API ni XML-RPC como «peticiones de aplicación» para que WordPress valide contraseñas de aplicación en ellas.
wp_is_application_passwords_supported: Comprueba si el entorno admite la funcionalidad (requiere HTTPS por defecto).

La clase principal es WP_Application_Passwords y los endpoints REST están en /wp/v2/users/<user_id>/application-passwords. La guía de integración original del equipo de WordPress Core sigue siendo la referencia técnica más completa.

Preguntas frecuentes

¿Se pueden usar para entrar en wp-admin?

No. Las contraseñas de aplicación solo funcionan para autenticar peticiones a la REST API y XML-RPC. Si intentas iniciar sesión en wp-login.php con una contraseña de aplicación, WordPress la rechazará.

Si cambio mi contraseña de WordPress, ¿dejan de funcionar?

No. Las contraseñas de aplicación son independientes de la contraseña del usuario. Cambiar una no afecta a la otra. Para invalidar una contraseña de aplicación tienes que anularla explícitamente.

¿Funcionan sin HTTPS?

Por defecto, no. WordPress las desactiva en conexiones HTTP para evitar que las credenciales viajen en texto plano. Se puede forzar con un filtro, pero solo tiene sentido en desarrollo local.

¿Puedo limitar lo que puede hacer cada contraseña?

No directamente. La contraseña hereda los permisos del usuario que la creó. No hay un sistema nativo de scopes o permisos por contraseña. La forma de limitar es crear la contraseña desde un usuario con el perfil mínimo necesario.

¿Son compatibles con plugins de seguridad?

Depende del plugin. Algunos como Wordfence, Shield Security o WP Cerber tienen compatibilidad específica para contraseñas de aplicación, otros pueden bloquearlas o interferir con la verificación de la API. Si usas un plugin de seguridad y las contraseñas de aplicación no te funcionan revisa sus ajustes de API y autenticación.

¿Cuántas puedo crear por usuario?

No hay límite definido por WordPress. Puedes crear tantas como necesites, aunque lo sensato es tener una por cada integración y anular las que ya no uses.

¿Qué pasa con las contraseñas existentes si desactivo la funcionalidad?

Si desactivas las contraseñas de aplicación con el filtro wp_is_application_passwords_available o un plugin de seguridad o rendimiento las contraseñas existentes dejan de funcionar. No se borran de la base de datos, pero WordPress no las valida. Si vuelves a activar la funcionalidad seguirán ahí y volverán a funcionar.