Cómo cargar credenciales para el testing

Para evaluar las áreas autenticadas de una aplicación, Strike necesita credenciales de acceso válidas. Cargar bien las credenciales es uno de los pasos más importantes del onboarding: si faltan o están incompletas, el testing no puede cubrir lo que está detrás del login.

Este artículo explica dónde se cargan, qué tipos existen y qué credenciales conviene entregar.

Dónde se cargan

Las credenciales se cargan en el segundo paso del formulario de creación del asset, con el botón Add credential. Se pueden agregar al crear el asset o más adelante, editándolo desde la sección de Details. Cada asset puede tener varias credenciales, y se pueden combinar distintos tipos.

Tipos de credenciales

Al agregar una credencial, se elige el tipo según cómo se accede a la aplicación:

• User & Password: usuario y contraseña. Es el caso más común, para aplicaciones con login estándar.

• Custom headers: para accesos que se autentican mediante headers específicos (por ejemplo, un token en un header de autorización).

• Cookies: para accesos basados en sesión, cuando el acceso se sostiene con cookies de sesión ya establecidas.

• API Keys: si la aplicación se accede mediante una API Key, se puede cargar como un custom header (por ejemplo, un header de autorización con la key). Es la forma de proporcionar API Keys hasta que exista una opción dedicada.

User & Password

Al elegir User & Password, se completa el username, la contraseña y el rol esperado de ese usuario. En Advanced configuration se puede configurar la autenticación de dos factores (2FA) si la aplicación la requiere.

Si la aplicación pide 2FA al ingresar, Strike puede completar el segundo factor igual que lo haría un usuario real. La configuración (app de autenticación / TOTP o código por email) se detalla en el artículo Cómo agregar autenticación de dos factores (2FA) a una credencial.

Custom headers

Se usa este tipo cuando la autenticación se resuelve con headers específicos. Se cargan el o los headers necesarios (por ejemplo, un header de autorización con su token) para que Strike acceda de forma autenticada.

Cookies

Se usa este tipo cuando el acceso se basa en una sesión ya iniciada. Se cargan las cookies de sesión que permiten a Strike mantener el acceso autenticado durante el testing.

Qué credenciales e información entregar

Para que Strike pueda acceder de forma completa, se recomiendan las siguientes opciones, en orden de preferencia:

1. Usuario de prueba registrado con un email @strike.email (recomendado). Se debe crear en la aplicación un usuario de prueba dedicado usando cualquier dirección @strike.email (por ejemplo, user01@strike.email o admin@strike.email). Las casillas @strike.email son buzones reales administrados por Strike: no es necesario crearlas ni compartir acceso a ellas. Strike lee automáticamente los emails de confirmación o verificación que lleguen ahí, lo que le permite completar el registro del usuario y, si aplica, el 2FA por email.

2. Reenvío a un email @strike.email. Si no es posible registrar un usuario nuevo, se puede configurar el reenvío de los correos de esa cuenta hacia una dirección @strike.email.

3. Usuario y contraseña con cualquier email. Si por razones de compliance no se puede usar una dirección @strike.email, se debe entregar un usuario y contraseña con el email que se use habitualmente. ⚠ Esta es la opción menos recomendada. Como Strike no tiene acceso a la casilla de email asociada, es la más propensa a trabarse: si el acceso requiere verificación por email o 2FA, no será posible completar la verificación por cuenta de Strike. En ese caso, conviene coordinar una alternativa en Additional notes (por ejemplo, cómo resolver el 2FA).

Si la cuenta usa 2FA, se recomienda siempre la opción @strike.email, porque le permite a Strike acceder al segundo factor directamente desde esa casilla.

Además de las credenciales en sí, se debe entregar la información de roles, permisos y privilegios de cada usuario. Esta información se puede detallar en Additional notes (ver siguiente sección). Es clave para que Strike evalúe bien los controles de acceso y evite falsos positivos en las pruebas de autorización.

Campo "Additional notes": aclaraciones importantes

Dentro de Advanced configuration existe el campo Additional notes, donde conviene detallar todo lo que ayude a usar las credenciales correctamente y a que la evaluación sea precisa. Ahí conviene aclarar, por ejemplo:

• Si el acceso es mediante SSO (single sign-on) y cómo funciona.

• Si hay una forma puntual de resolver el 2FA.

• Si se quiere proporcionar acceso a la casilla de email asociada a la credencial, esos datos se pueden incluir ahí.

• Los privilegios y accesos del rol: qué puede hacer ese usuario, a qué tiene acceso y las particularidades de sus permisos. Esto es clave para evaluar bien los controles de acceso y evitar falsos positivos en las pruebas de autorización.

• Cómo funciona el modelo de permisos (RBAC) y cómo se gestionan los usuarios (alta, baja y modificación).

• Cualquier particularidad de los mecanismos de authentication / authorization.

Cuanta más información se entregue, menos idas y vueltas y más rápido puede arrancar el testing.

Preguntas frecuentes

¿Dónde se cargan las credenciales?

En el asset, con el botón Add credential. Se puede hacer al crear el asset o después, editándolo desde Details.

¿Qué tipos de credenciales se pueden cargar?

Tres, según cómo se accede a la aplicación: User & Password (usuario y contraseña), Cookies (accesos por sesión) y Custom headers (autenticación por headers). Las API Keys también se cargan, como un custom header.

¿Se puede cargar más de una credencial en un asset?

Sí. Un asset puede tener varias credenciales, y se pueden combinar distintos tipos.

¿Qué credenciales conviene entregar?

Lo ideal es un usuario de prueba dedicado registrado con una dirección @strike.email, porque Strike lee automáticamente los emails que llegan a esa casilla (confirmación, verificación, 2FA por email). Si no es posible, se puede reenviar los correos a una dirección @strike.email. Y si por compliance no se puede usar ese dominio, un usuario y contraseña con cualquier email (es la opción menos recomendada, porque puede trabarse con verificaciones por email o 2FA).

¿Es necesario crear la casilla @strike.email o dar acceso a ella?

No. Las casillas @strike.email son buzones reales administrados por Strike. Solo es necesario registrar al usuario de prueba en la aplicación usando una dirección @strike.email (por ejemplo, user01@strike.email); Strike lee los emails desde su lado.

¿Se pueden actualizar las credenciales después de crear el asset?

Sí. El asset se edita desde Details y se pueden actualizar o agregar credenciales cuando sea necesario.

Mi aplicación usa 2FA, ¿cómo se configura?

Al agregar una credencial de User & Password, en Advanced configuration se puede configurar el 2FA. El detalle de cada método está en Cómo agregar autenticación de dos factores (2FA) a una credencial.

¿Cómo se accede si la aplicación usa SSO?

Se debe indicar en el campo Additional notes que el acceso es mediante SSO y cómo funciona, para que el equipo pueda acceder correctamente.

¿Para qué sirven las "Additional notes"?

Es un campo dentro de Advanced configuration, disponible en todos los tipos de credencial. Ahí conviene aclarar roles y privilegios, SSO, formas particulares de 2FA, o acceso a la casilla de email asociada.

¿Qué pasa si se carga mal una credencial?

El Pre-flight Check corre antes de que comience el testing y detecta problemas de acceso. Si el login falla (por ejemplo, contraseña incorrecta), queda reportado para poder corregir la credencial y volver a ejecutar, sin perder cobertura.