How to upload credentials for testing

To evaluate the authenticated areas of an application, Strike needs valid access credentials. Adding credentials correctly is one of the most important steps of onboarding: if they are missing or incomplete, testing cannot cover what is behind the login.

This article explains where they are added, which types exist, and which credentials you should provide.

Where they are added

Credentials are added in the Settings step of the asset creation form, with the Add credential button. They can be added when creating the asset or later, by editing it from the Details section. Each asset can have multiple credentials, and different types can be combined.

You can also configure an asset's credentials from a Threat Emulation, with Set up in the Scoping step. To see how credentials are shared between the asset and the Threat Emulation, see How configuration is inherited between an asset and a Threat Emulation.

Credential types

When adding a credential, you choose the type based on how the application is accessed:

• User & Password: username and password. This is the most common case, for applications with a standard login.

• Custom headers: for access that is authenticated through specific headers (for example, a token in an authorization header).

• Cookies: for session-based access, when access is maintained with already established session cookies.

• API Keys: if the application is accessed with an API Key, it can be added as a custom header (for example, an authorization header with the key). This is the way to provide API Keys until a dedicated option is available.

User & Password

When you choose User & Password, you fill in the username, the password, and the expected role of that user. In Advanced configuration, you can configure two-factor authentication (2FA) if the application requires it.

If the application asks for 2FA when logging in, Strike can complete the second factor just as a real user would. The configuration (authenticator app / TOTP or email code) is detailed in How to add two-factor authentication (2FA) to a credential.

Custom headers

Use this type when authentication is handled with specific headers. You add the required header or headers (for example, an authorization header with its token) so that Strike can access in an authenticated way.

Cookies

Use this type when access is based on an already started session. You add the session cookies that allow Strike to maintain authenticated access during testing.

Which credentials and information to provide

For Strike to have complete access, the following options are recommended, in order of preference:

1. Test user registered with an @strike.email email address (recommended). Create a dedicated test user in the application using any @strike.email address (for example, [email protected] or [email protected]). @strike.email addresses are real mailboxes managed by Strike: you don't need to create them or share access to them. Strike automatically reads the confirmation or verification emails that arrive there, which allows it to complete the user registration and, if applicable, 2FA via email.

2. Forwarding to an @strike.email address. If it's not possible to register a new user, you can set up forwarding of that account's emails to an @strike.email address.

3. Username and password with any email address. If, for compliance reasons, an @strike.email address cannot be used, provide a username and password with the email address you normally use. This is the least recommended option: since Strike has no access to the associated mailbox, it is the most likely to get stuck. If access requires email verification or 2FA, Strike will not be able to complete the verification on its own. In that case, it's a good idea to coordinate an alternative in Additional notes (for example, how to handle 2FA).

If the account uses 2FA, the @strike.email option is always recommended, because it allows Strike to access the second factor directly from that mailbox. To see in detail how each option affects coverage, see How to provide test credentials for Strike's AI agent.

In addition to the credentials themselves, provide the information about each user's roles, permissions, and privileges. You can detail this information in Additional notes (see next section). It's key for Strike to properly evaluate access controls and avoid false positives in authorization tests.

"Additional notes" field: important clarifications

Within Advanced configuration there is the Additional notes field, where you should detail anything that helps use the credentials correctly and makes the evaluation accurate. For example, it's a good place to clarify:

• Whether access is through SSO (single sign-on) and how it works.

• Whether there is a specific way to handle 2FA.

• If you want to provide access to the mailbox associated with the credential, you can include those details there.

• The role's privileges and access: what that user can do, what they have access to, and the particulars of their permissions. This is key to properly evaluating access controls and avoiding false positives in authorization tests.

• How the permission model (RBAC) works and how users are managed (creation, deletion, and modification).

• Any particularities of the authentication / authorization mechanisms.

The more information you provide, the less back-and-forth and the sooner testing can start.

Frequently asked questions

Where are credentials added?

In the asset, with the Add credential button. You can do it when creating the asset or afterwards, by editing it from Details. They can also be configured from a Threat Emulation, with Set up.

What types of credentials can be added?

Three, depending on how the application is accessed: User & Password (username and password), Cookies (session-based access), and Custom headers (header-based authentication). API Keys can also be added, as a custom header.

Can more than one credential be added to an asset?

Yes. An asset can have multiple credentials, and different types can be combined.

Which credentials should I provide?

Ideally, a dedicated test user registered with an @strike.email address, because Strike automatically reads the emails that arrive in that mailbox (confirmation, verification, 2FA via email). If that's not possible, you can forward the emails to an @strike.email address. And if, for compliance reasons, that domain cannot be used, a username and password with any email address (this is the least recommended option, because it can get stuck on email verifications or 2FA).

Do I need to create the @strike.email mailbox or give access to it?

No. @strike.email addresses are real mailboxes managed by Strike. You only need to register the test user in the application using an @strike.email address (for example, [email protected]); Strike reads the emails on its side.

Can credentials be updated after creating the asset?

Yes. The asset is edited from Details, and you can update or add credentials whenever needed.

My application uses 2FA. How do I configure it?

When adding a User & Password credential, you can configure 2FA in Advanced configuration. The details of each method are in How to add two-factor authentication (2FA) to a credential.

How is access handled if the application uses SSO?

Indicate in the Additional notes field that access is through SSO and how it works, so the team can access it correctly.

What are "Additional notes" for?

It's a field within Advanced configuration, available for all credential types. It's the place to clarify roles and privileges, SSO, particular 2FA methods, or access to the associated mailbox.

What happens if a credential is added incorrectly?

The Pre-flight Check runs at the start of each run and detects access problems. If the login fails (for example, due to an incorrect password), the run doesn't start and you see a notice describing the problem. Fix the credential and click Retry. The Pre-flight Check does not consume credits. For more detail, see How the Pre-flight Check works.