Cómo probar correos de restablecimiento de contraseña de principio a fin

Empieza con dos casos de solicitud pública

Crea un usuario conocido cuya dirección sea un destinatario nuevo de InboxTap y envía una solicitud de restablecimiento para esa cuenta. Envía el mismo formulario público con otra dirección desconocida y compara el estado y la respuesta visible para el usuario.

El endpoint no debe revelar si existe una cuenta. Evita exigir tiempos transcurridos exactamente iguales en una batería de navegador, porque el planificador y la base de datos introducen ruido y vuelven frágil esa comprobación; sigue las recomendaciones de seguridad del proveedor y usa pruebas específicas de nivel inferior para las mitigaciones temporales.

• Guía de OWASP para contraseñas olvidadas ↗

Valida el destino del restablecimiento

Espera una URL que contenga la ruta de restablecimiento de la aplicación y analízala antes de navegar. Compara el origen y la ruta exactos esperados para que una URL base mal formada, un host no fiable o un retorno incorrecto no queden ocultos por una redirección del navegador.

Trata la URL completa como una credencial al portador. No la imprimas, no la interpoles en el título de la prueba ni adjuntes una captura de pantalla sin protección que muestre la barra de direcciones.

await requestPasswordReset(inbox.address);

const rawUrl = await inbox.waitForLink({
  contains: "/reset-password",
  timeoutMs: 20_000,
});

const resetUrl = new URL(rawUrl);
expect(resetUrl.origin).toBe(appOrigin);
expect(resetUrl.pathname).toBe("/reset-password");

await completePasswordReset(resetUrl.href, newPassword);
expect(await signIn(inbox.address, oldPassword)).toBe(false);
expect(await signIn(inbox.address, newPassword)).toBe(true);

Demuestra que la contraseña se sustituyó

Completa el formulario real de restablecimiento con una contraseña que cumpla la política actual de la aplicación. Después, cierra la sesión o crea un contexto de navegador limpio, confirma que la contraseña anterior falla y que la nueva autentica la misma cuenta.

Comprueba la identidad o el estado de la sesión respaldados por el servidor en lugar de depender solo de un aviso de éxito. Verifica también la validación de una contraseña nueva débil o que no coincida cuando esa lógica forme parte de la página de restablecimiento.

Rechaza la reutilización, la caducidad y la manipulación

Intenta reutilizar la URL ya canjeada y verifica que no pueda volver a cambiar la contraseña. Ejercita un token caducado con un reloj controlado o una vigencia específica de prueba y modifica el token para demostrar que se rechaza una entrada mal formada.

El fallo no debe exponer el token, detalles internos de la política de contraseñas ni datos de la cuenta en la página o en los registros habituales del servidor. Se puede ofrecer al usuario una ruta segura para solicitar otro restablecimiento.

Comprueba la política de sesiones

Decide si un restablecimiento de contraseña revoca todas las sesiones existentes, solo las demás o ninguna. Better Auth, por ejemplo, ofrece revokeSessionsOnPasswordReset en lugar de imponer un único resultado a todas las aplicaciones.

Crea las sesiones pertinentes antes del restablecimiento e inspecciónalas después del cambio. InboxTap no puede deducir esta política del correo; hay que comprobarla en el sistema de autenticación.

• Documentación del correo de restablecimiento en Better Auth ↗

Separa la entrega de la deduplicación de negocio

Usa toHaveDeliveredOnce() después de saber que existe el primer mensaje de restablecimiento cuando el producto prometa una entrega por solicitud. Su intervalo de calma opcional puede observar un reintento inmediato, pero no demuestra que ningún trabajo posterior vaya a ejecutarse.

La persistencia de colas, las claves de idempotencia, la limitación de frecuencia y la deduplicación pertenecen a las pruebas de la aplicación. InboxTap puede inyectar un 451 o una desconexión para activar esas rutas y mostrar qué intentos SMTP terminaron, pero no controla el sistema de trabajos.

Genera pruebas mínimas y seguras

Prefiere pruebas que registren el resultado de la comprobación, participantes seudonimizados, la forma de la URL y el resultado final de la aplicación sin conservar el secreto reutilizable. Excluye la fuente RFC sin procesar salvo que una necesidad concreta de diagnóstico compense el riesgo de divulgación.

Los informes de InboxTap ocultan superficies habituales de tokens y direcciones, escapan el marcado capturado y mantienen límites de tamaño, pero esa protección no ofrece garantías absolutas. Añade patrones propios del proyecto y revisa el artefacto antes de compartirlo.