¿Qué permisos tiene una Application Password de WAP?

Una contraseña de aplicación etiquetada como WAP no es un rol independiente. Autentica la solicitud como el usuario de WordPress que la posee. La autoridad efectiva depende de los roles y capacidades de ese usuario, del endpoint o ability invocado y de cualquier comprobación adicional de permisos aplicada por el plugin integrador.

La etiqueta, el transporte o el descubrimiento correcto de una herramienta no amplían esas capacidades. Para reducir el impacto, utilice una identidad de WordPress separada con las capacidades mínimas necesarias para el flujo aprobado.

Causas probables

  • La credencial está asociada a un usuario de WordPress distinto del que espera el cliente.
  • El asistente usa una cuenta humana de administrador en lugar de una identidad dedicada y limitada.
  • El usuario autenticado de WordPress no tiene la capacidad exigida por el endpoint o la herramienta.
  • El flujo solicita escritura mientras la identidad está limitada deliberadamente a lectura.
  • Varias credenciales con nombres parecidos hacen ambiguos el propietario y el uso activo.

Secuencia de diagnóstico

  1. Verifique que el nombre de usuario enviado por el cliente coincida con el propietario de la Application Password.
  2. Use una comprobación mínima de identidad autenticada para confirmar qué usuario representa la solicitud.
  3. Compare las capacidades del usuario autenticado con la acción requerida por la ruta o herramienta.
  4. Repita una lectura conocida y limitada que deba estar permitida para esta identidad.
  5. Intente una escritura deliberadamente prohibida para confirmar que el límite sigue rechazándola.
  6. Revise la sección de Application Passwords del perfil relevante sin exponer ningún secreto.

Aplicar la corrección mínima

  1. Cree una identidad dedicada de WordPress en vez de reutilizar al administrador humano.
  2. Seleccione el nivel de acceso de WordPress más bajo que complete la acción aprobada.
  3. Cree una Application Password con nombre para la identidad dedicada y una sola finalidad.
  4. Revoque credenciales confirmadas como no utilizadas o innecesarias.
  5. Documente quién crea, rota, reutiliza y revoca la credencial, y qué activa cada cambio.

Verificar el resultado

  • La solicitud autenticada corresponde al usuario dedicado previsto.
  • La lectura limitada aprobada se completa con una respuesta reproducible.
  • Una escritura deliberadamente prohibida sigue siendo rechazada.
  • Tras la revocación, la misma credencial ya no puede autenticar.

Qué no hacer

  • No conceda acceso de administrador solo para que una prueba de conexión funcione.
  • No confunda autenticación correcta con permiso para ejecutar todas las acciones de WordPress.
  • No trate todo 403 como una conexión rota; puede ser el rechazo de permisos correcto.
  • No incluya una Application Password, encabezado Authorization, token o cookie en prompts, tickets, registros o capturas.
  • No pase de una identidad limitada a Full Power sin flujo separado, staging y reversión aprobados.

Guías relacionadas

Fuentes y verificación

Esta página se verificó a partir de las siguientes fuentes primarias. Última revisión de las fuentes: .