Contraseñas de aplicación en WordPress: REST API segura

Aprende a usar contraseñas de aplicación en WordPress para autenticar integraciones con la REST API sin compartir tu contraseña principal, con HTTPS, permisos mínimos, rotación y revocación.

Portátil conectado de forma segura a servidores mediante credenciales de aplicación para la REST API de WordPress

Conectar WordPress con un script, una aplicación o un servicio externo no debería obligarte a compartir la contraseña principal de tu cuenta. WordPress incluye las contraseñas de aplicación —Application Passwords— precisamente para separar el acceso programático del inicio de sesión habitual.

Son útiles cuando una integración necesita autenticarse contra la REST API para consultar contenido privado, crear entradas, subir medios o ejecutar otras acciones que el usuario asociado tenga permitidas. La clave está en tratarlas como credenciales técnicas independientes: una por integración, siempre sobre HTTPS y revocables cuando dejan de ser necesarias.

Qué es una contraseña de aplicación en WordPress

Una contraseña de aplicación es una credencial generada para un usuario concreto de WordPress y destinada al acceso mediante aplicaciones o scripts. No sustituye a la contraseña habitual de ese usuario ni sirve para iniciar sesión de forma interactiva en wp-login.php.

WordPress las incorporó al núcleo en la versión 5.6. La documentación oficial de Application Passwords las describe como credenciales por aplicación que pueden revocarse individualmente. Además, WordPress almacena información de uso como la fecha del último acceso y la IP asociada, lo que facilita detectar integraciones antiguas o credenciales que conviene retirar.

Por qué es mejor que compartir tu contraseña principal

El beneficio principal es el aislamiento. Si utilizas una misma contraseña humana en el panel de WordPress y en varias integraciones, cualquier cambio o incidente afecta a todo el conjunto. Con una contraseña de aplicación puedes retirar únicamente el acceso de una herramienta sin cambiar la credencial con la que entras al panel.

  • Separación: cada integración puede tener su propia credencial.
  • Revocación: puedes desactivar una contraseña concreta sin afectar a las demás.
  • Trazabilidad: WordPress muestra información de uso de cada credencial.
  • Menor exposición: la contraseña principal del usuario no necesita salir del flujo de acceso habitual.

Esto no convierte automáticamente una integración en segura. La aplicación que recibe la contraseña sigue teniendo que protegerla correctamente, limitar su exposición y evitar registrarla en logs, repositorios o código público.

Cuándo tiene sentido utilizarla

Las contraseñas de aplicación encajan especialmente bien cuando una herramienta externa necesita autenticarse contra WordPress. Algunos ejemplos habituales son un proceso de publicación automatizada, un script de mantenimiento, una integración que sube archivos o una aplicación que consulta recursos privados mediante la REST API.

Si estás diseñando un flujo más amplio entre WordPress, CRM, correo o servicios externos, conviene separar primero qué parte necesita autenticación directa contra WordPress. La guía sobre webhooks y APIs en WordPress explica cómo decidir qué sistema debe iniciar cada acción y cuándo merece la pena utilizar un servicio intermedio.

Cómo crear una contraseña de aplicación

En una instalación compatible, el usuario puede generar estas credenciales desde su perfil en WordPress. El proceso general es:

  1. Accede al panel de administración.
  2. Abre el perfil del usuario que utilizará la integración.
  3. Localiza la sección de contraseñas de aplicación.
  4. Asigna un nombre reconocible, por ejemplo Integración CRM o Script contenidos.
  5. Genera la credencial y cópiala en el gestor seguro donde vaya a utilizarse.
  6. No guardes la contraseña en texto plano dentro de código, repositorios o documentación pública.

La contraseña se muestra cuando se crea. Después, WordPress permite revisar y revocar el registro, pero no está pensado para volver a mostrar el secreto original. La documentación de WordPress recomienda tratar estas credenciales como secretos y rotarlas cuando sea necesario.

Autenticación contra la REST API

La REST API de WordPress expone recursos mediante HTTP y utiliza JSON como formato de intercambio. El índice de la API suele estar disponible bajo /wp-json/, y los recursos del núcleo utilizan rutas como /wp-json/wp/v2/posts.

Para una integración externa, WordPress permite utilizar la contraseña de aplicación mediante autenticación HTTP Basic sobre HTTPS. Un ejemplo de prueba con curl sería:

curl --user "USUARIO:CONTRASENA_DE_APLICACION" \
  https://ejemplo.com/wp-json/wp/v2/users/me

Este ejemplo solo ilustra el mecanismo. No copies una credencial real en el historial de comandos de un equipo compartido, en capturas, tickets o documentación que pueda quedar expuesta.

HTTPS no es opcional

Las credenciales de Basic Auth deben viajar por una conexión cifrada. WordPress indica expresamente que las contraseñas de aplicación están pensadas para utilizarse sobre HTTPS; sin cifrado, una credencial transmitida por la red podría quedar expuesta.

Antes de integrar nada, comprueba que el sitio utiliza HTTPS correctamente y que el cliente se conecta al dominio definitivo mediante una cadena TLS válida. Si un proxy, CDN o balanceador participa en la conexión, verifica también que WordPress detecta correctamente el entorno seguro.

Usa un usuario con los permisos necesarios, no más

Una contraseña de aplicación está vinculada a un usuario de WordPress. Por eso, al diseñar una integración conviene revisar qué operaciones necesita realmente realizar y asociarla a una cuenta con capacidades acordes a esa función.

Si un proceso solo necesita publicar contenido, no tiene sentido concederle capacidades administrativas ajenas a esa tarea. Reducir privilegios limita el impacto potencial de una credencial comprometida y simplifica la revisión posterior.

Una contraseña distinta para cada integración

Reutilizar la misma credencial en varios servicios elimina buena parte de la ventaja del sistema. Si una de esas herramientas deja de utilizarse o presenta un incidente, no sabrás qué accesos puedes revocar sin interrumpir los demás.

Una práctica operativa sencilla es mantener una ficha por integración con:

  • nombre de la aplicación;
  • usuario de WordPress asociado;
  • finalidad;
  • fecha de alta;
  • responsable técnico;
  • ubicación segura del secreto;
  • último uso revisado;
  • procedimiento de revocación.

No anotes la contraseña en esa ficha. Documenta dónde se gestiona el secreto, no el secreto en sí.

Cómo revocar o rotar una credencial

Cuando una integración deja de usarse, cambia de proveedor o existe sospecha de exposición, revoca su contraseña de aplicación y genera otra si el servicio sigue siendo necesario. WordPress permite gestionar estas credenciales individualmente desde el perfil del usuario.

También pueden administrarse mediante WP-CLI en entornos donde exista acceso por terminal. La guía oficial de administración documenta la creación, listado y eliminación de contraseñas de aplicación, así como recomendaciones de rotación.

Errores frecuentes al integrar la REST API

Cuando una petición autenticada devuelve un 401 o 403, no conviene asumir directamente que la contraseña está mal. Revisa el flujo completo:

  1. HTTPS: confirma que el endpoint se consume mediante una URL segura.
  2. Usuario: utiliza el nombre de usuario correcto junto a la contraseña de aplicación.
  3. Cabecera Authorization: algunos proxies o configuraciones pueden eliminarla antes de que llegue a WordPress.
  4. Permisos: el usuario debe tener capacidad para ejecutar la operación solicitada.
  5. Plugins o código: comprueba que ninguna capa de seguridad haya desactivado las contraseñas de aplicación.
  6. Endpoint: verifica método HTTP, ruta y parámetros antes de modificar credenciales.

La documentación oficial de autenticación de la REST API distingue entre autenticación mediante cookies para acciones dentro del propio WordPress y contraseñas de aplicación para acceso externo.

Qué no deberías hacer

  • Compartir la contraseña principal del administrador con una integración.
  • Guardar contraseñas de aplicación dentro de código versionado.
  • Reutilizar una única credencial para todos los servicios.
  • Conceder permisos administrativos si el flujo no los necesita.
  • Mantener credenciales de herramientas que ya no existen.
  • Enviar secretos a logs, sistemas de analítica o mensajes de error visibles.
  • Desactivar controles de seguridad solo para “hacer funcionar” una petición sin diagnosticar el problema.

Checklist antes de poner la integración en producción

  1. Define exactamente qué operaciones necesita realizar la integración.
  2. Utiliza un usuario con los permisos mínimos necesarios.
  3. Crea una contraseña exclusiva para esa aplicación.
  4. Guarda el secreto en un sistema apropiado para credenciales.
  5. Comprueba HTTPS de extremo a extremo.
  6. Prueba lectura y escritura únicamente sobre recursos controlados.
  7. Registra errores sin incluir secretos ni datos innecesarios.
  8. Documenta cómo revocar la credencial.
  9. Revisa periódicamente si la integración sigue utilizándose.

REST API segura significa controlar todo el ciclo

La contraseña de aplicación resuelve una parte importante de la autenticación, pero no sustituye al diseño de seguridad completo. Una integración fiable necesita permisos adecuados, transporte cifrado, secretos protegidos, validación de entradas, gestión de errores y un procedimiento claro de baja.

Si estás conectando WordPress con otras plataformas, el servicio de automatización e integraciones está orientado a diseñar estos flujos con una arquitectura mantenible. También puedes contarme qué sistemas necesitas conectar y revisar el enfoque antes de llevarlo a producción.

Fuentes oficiales

Foto del avatar
GonzaloCN
Artículos: 49

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *