Contraseñas de aplicación en WordPress: qué son y cómo usarlas de forma segura

Desde WordPress 5.6 existe una función poco conocida y muy útil: las contraseñas de aplicación. Permiten que aplicaciones externas (la app móvil de WordPress, un cliente de la API REST, una herramienta de publicación, una integración con otro servicio o un script propio) se conecten a tu sitio sin conocer tu contraseña real. En esta guía vemos qué son, dónde se crean, cómo usarlas desde la línea de comandos, por qué a veces devuelven un error 401 aunque la clave sea correcta, y los errores de seguridad más comunes.
Qué es una contraseña de aplicación
Es una clave de 24 caracteres que WordPress genera para un uso concreto y que se muestra en seis grupos de cuatro. Tiene propiedades que la hacen más segura que tu contraseña normal:
- Solo sirve para la API REST y XML-RPC: no permite entrar en wp-admin ni en la pantalla de inicio de sesión.
- Puedes crear una distinta por cada aplicación y revocarlas individualmente, sin cambiar tu contraseña real.
- WordPress registra la fecha del último uso de cada una y la dirección IP desde la que se utilizó.
- No caducan por sí solas: siguen funcionando hasta que las revocas.
Un matiz que conviene tener claro: la contraseña de aplicación hereda los permisos del usuario que la creó. Si es un administrador, quien la tenga podrá publicar, editar y borrar contenido a través de la API con permisos de administrador. Más abajo veremos cómo limitar ese riesgo.
Dónde se crean
- Entra en tu panel y ve a Usuarios → Perfil (o a editar el usuario que corresponda).
- Baja hasta la sección Contraseñas de aplicación.
- Escribe un nombre descriptivo (por ejemplo, «App móvil» o «Script de copias») y pulsa Añadir nueva contraseña de aplicación.
- Copia la clave con formato
xxxx xxxx xxxx xxxx xxxx xxxx: solo se muestra una vez. Los espacios son decorativos; funciona con o sin ellos.
Si no te aparece la sección
- El sitio debe servirse por HTTPS. En sitios sin SSL, WordPress oculta la función por seguridad (salvo en entornos de desarrollo local).
- Algunos plugins de seguridad la desactivan; busca la opción «Application Passwords» en sus ajustes. También puede estar desactivada por código con el filtro
wp_is_application_passwords_available. - Necesitas WordPress 5.6 o superior.
- Puede estar desactivada para un usuario concreto con el filtro
wp_is_application_passwords_available_for_user.
Cómo usarla: ejemplos con la API REST
La contraseña de aplicación se envía como autenticación básica HTTP junto a tu nombre de usuario. Para comprobar que funciona, pide a WordPress que te diga quién eres:
# curl (Linux, macOS y Windows 10/11)
curl -u "tu-usuario:xxxx xxxx xxxx xxxx xxxx xxxx" "https://tusitio.com/wp-json/wp/v2/users/me?context=edit"
# PowerShell
$h = @{Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("tu-usuario:xxxx xxxx xxxx xxxx xxxx xxxx"))}
Invoke-RestMethod "https://tusitio.com/wp-json/wp/v2/users/me?context=edit" -Headers $h
Si todo va bien, la respuesta es un JSON con tu id, tu nombre y tus roles. A partir de ahí puedes, por ejemplo, crear un borrador de una entrada:
curl -u "tu-usuario:xxxx xxxx xxxx xxxx xxxx xxxx" -X POST "https://tusitio.com/wp-json/wp/v2/posts" \
-H "Content-Type: application/json" \
-d '{"title":"Entrada de prueba","content":"Hola desde la API","status":"draft"}'
Crear las entradas siempre en estado draft es una buena costumbre: así una automatización jamás publica nada sin que una persona lo revise.
Error 401 «No estás conectado»: cómo diagnosticarlo
El problema más frecuente al empezar es un error 401 con el mensaje rest_not_logged_in («No estás conectado»), aunque la clave sea correcta. Revisa las causas en este orden, de la más a la menos probable:
- El nombre de usuario no es el correcto. Debe ser tu nombre de usuario de acceso (el login) o tu correo electrónico. No sirve el nombre público que se muestra en las entradas ni el slug del autor que aparece en las URL. Un ejemplo habitual: si tu login es un correo electrónico, el slug público es una versión transformada (
usuario-dominio-com) y no es el que debes usar. En la práctica, con un usuario que no existe, WordPress puede responder exactamente igual que si no enviaras ninguna credencial, por lo que el error no te avisa de que el problema es el nombre. Comprueba el nombre exacto en Usuarios → Todos los usuarios, en la columna «Nombre de usuario». - La clave está revocada o mal copiada. Genera una nueva y pruébala de inmediato.
- El sitio no se sirve por HTTPS o una redirección intermedia (de
httpahttpso de sinwwwawww) descarta la cabecera de autenticación. Usa siempre la URL final. - Tu hosting elimina la cabecera
Authorization. Algunos servidores con PHP en modo CGI o FastCGI la descartan. Se suele solucionar con estas líneas en el archivo.htaccess:
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
- Un plugin de seguridad o un cortafuegos bloquea la API REST para usuarios no autenticados o desactiva las contraseñas de aplicación.
Una forma rápida de saber si el problema es el nombre de usuario o el servidor es probar con una clave claramente falsa y con el nombre de usuario correcto: si el error cambia (por ejemplo, a «contraseña incorrecta»), la cabecera sí llega y el fallo estaba en la clave; si es idéntico, repasa el nombre de usuario y, después, la configuración del servidor.
Ejemplo práctico: listar tus últimas entradas
Un caso sencillo y seguro para estrenar la clave es consultar tus últimas entradas, incluidos los borradores, con PowerShell:
$h = @{Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("tu-usuario:xxxx xxxx xxxx xxxx xxxx xxxx"))}
Invoke-RestMethod "https://tusitio.com/wp-json/wp/v2/posts?status=publish,draft&per_page=5&_fields=id,status,title" -Headers $h |
ForEach-Object { "{0} [{1}] {2}" -f $_.id, $_.status, $_.title.rendered }
El parámetro _fields limita la respuesta a los datos que necesitas y la hace mucho más rápida. Si la respuesta incluye tus borradores, la autenticación funciona correctamente: sin credenciales, la API no te dejaría consultar entradas que no son públicas y devolvería un error.
Buenas prácticas de seguridad
- Una contraseña por aplicación. Si una herramienta se ve comprometida, revocas solo la suya.
- Crea un usuario específico con el rol mínimo necesario. Si una integración solo tiene que crear borradores, no uses tu cuenta de administrador: crea un usuario con rol de Autor o Editor y genera la clave en su perfil. Así, una fuga no compromete todo el sitio.
- Nómbralas bien. «Prueba 3» no te dirá nada dentro de un año; «Plugin de newsletters» sí.
- Revísalas cada pocos meses. En Usuarios → Perfil verás el último uso y la IP de cada una: las que lleven meses sin usarse, fuera.
- Revoca al desinstalar. Si dejas de usar la aplicación, elimina también su contraseña.
- Nunca las publiques. Ni en capturas de pantalla, ni en repositorios de código, ni en foros de soporte, ni en un chat. Si ocurre, revócala inmediatamente.
Ten presente también que las contraseñas de aplicación no pasan por la verificación en dos pasos del inicio de sesión: ese es precisamente su propósito, pero implica que quien la obtenga puede actuar con los permisos del usuario sin necesidad de segundo factor. Trátalas con el mismo cuidado que una clave privada. Si quieres repasar cómo gestionar claves importantes, tienes recomendaciones prácticas en nuestra guía para crear contraseñas seguras.
Qué hacer si se filtra una contraseña de aplicación
- Entra en Usuarios → Perfil y revoca la clave afectada (o todas, con el botón de revocar todas).
- Revisa las últimas entradas, páginas, comentarios y usuarios creados o modificados, por si alguien ha actuado con ella.
- Cambia la contraseña real de ese usuario si sospechas que se ha expuesto algo más.
- Genera una clave nueva solo para la aplicación legítima.
Muchas filtraciones empiezan con un correo que suplanta a un servicio de confianza y te pide «verificar» tu cuenta. Aprende a reconocerlos en qué es el phishing y cómo detectarlo.
Automatizar tareas con ellas
Un uso muy común es el de scripts programados que consultan o actualizan el sitio, por ejemplo para generar informes de contenido o para comprobar que no hay entradas programadas inesperadas. Si el script se ejecuta en un servidor Linux, puedes lanzarlo periódicamente con cron. Guarda siempre la clave en un archivo de configuración con permisos restringidos o en una variable de entorno, nunca escrita dentro del código del script.
Preguntas frecuentes
¿Puedo ver una contraseña de aplicación después de crearla?
No. WordPress solo la muestra en el momento de crearla y almacena únicamente un código derivado. Si la pierdes, revócala y crea otra.
¿Necesito instalar algún plugin?
No. Es una función del núcleo de WordPress desde la versión 5.6. Los plugins solo intervienen si quieres desactivarla o restringirla.
¿Puedo limitar una contraseña de aplicación a ciertas acciones?
Las contraseñas de aplicación no tienen permisos propios: usan los del usuario. Por eso la forma de limitarlas es crear un usuario con el rol mínimo imprescindible, como se explicó arriba.
Conclusión
Las contraseñas de aplicación son la forma correcta de conectar cualquier herramienta externa a WordPress: dan acceso limitado a la API, trazable y revocable. Si hoy tienes tu contraseña principal escrita en la configuración de alguna aplicación, dedica cinco minutos a sustituirla por una clave de aplicación, y si algo falla con un 401, empieza siempre por comprobar que estás usando el nombre de usuario exacto.