How to upload credentials for testing
Last updated: July 27, 2026
To evaluate the authenticated areas of an application, Strike needs valid access credentials. Uploading credentials correctly is one of the most important onboarding steps: if they're missing or incomplete, testing can't cover what's behind the login.
This article explains where to upload them, what types exist, and which credentials are best to provide.
Where to upload them
Credentials are uploaded in the second 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 several credentials, and different types can be combined.
Credential types
When adding a credential, the type is chosen 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's 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 through an API Key, it can be uploaded as a custom header (for example, an authorization header with the key). This is the way to provide API Keys until a dedicated option exists.
User & Password
When choosing User & Password, the username, password, and expected role for that user are filled in. Under Advanced configuration, two-factor authentication (2FA) can be configured if the application requires it.
If the application asks for 2FA when logging in, Strike can complete the second factor just like a real user would. The configuration (authenticator app / TOTP or email code) is detailed in the article How to add two-factor authentication (2FA) to a credential.
Custom headers
Use this type when authentication is resolved through specific headers. The needed header(s) are uploaded (for example, an authorization header with its token) so Strike can access the application in an authenticated way.
Cookies
Use this type when access is based on an already-started session. The session cookies that let Strike keep the access authenticated during testing are uploaded here.
Which credentials and information to provide
For Strike to be able to access the application fully, the following options are recommended, in order of preference:
A test user registered with a
@strike.emailaddress (recommended). Create a dedicated test user in the application using any@strike.emailaddress (for example,[email protected]or[email protected]).@strike.emailinboxes are real mailboxes managed by Strike: there's no need to create them or share access to them. Strike automatically reads confirmation or verification emails that arrive there, which lets it complete the user's registration and, if applicable, email-based 2FA.Forwarding to a
@strike.emailaddress. If registering a new user isn't possible, emails from that account can be forwarded to a@strike.emailaddress.Username and password with any email. If, for compliance reasons, a
@strike.emailaddress can't be used, provide a username and password with the email normally used. ⚠ This is the least recommended option. Since Strike doesn't have access to the associated email inbox, it's the most prone to getting stuck: if access requires email verification or 2FA, Strike won't be able to complete verification on its own. In that case, coordinate an alternative in Additional notes (for example, how to resolve 2FA).
If the account uses 2FA, the @strike.email option is always recommended, since it lets Strike access the second factor directly from that inbox.
In addition to the credentials themselves, information about each user's roles, permissions, and privileges should be provided. This can be detailed in Additional notes (see next section). It's key for Strike to properly evaluate access controls and avoid false positives in authorization testing.
The "Additional notes" field: important clarifications
Inside Advanced configuration there's an Additional notes field, where it's worth detailing anything that helps use the credentials correctly and makes the evaluation accurate. It's worth clarifying there, for example:
Whether access is through SSO (single sign-on) and how it works.
Whether there's a specific way to resolve 2FA.
If access to the email inbox associated with the credential should be provided, those details can be included there.
The role's privileges and access: what that user can do, what they have access to, and the particularities of their permissions. This is key for properly evaluating access controls and avoiding false positives in authorization testing.
How the permissions model (RBAC) works and how users are managed (creation, deactivation, and modification).
Any particularity of the authentication / authorization mechanisms.
The more information provided, the less back-and-forth and the faster testing can start.
Frequently asked questions
Where are credentials uploaded?
On the asset, with the Add credential button. This can be done when creating the asset or afterward, by editing it from Details.
What types of credentials can be uploaded?
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 are also uploaded, as a custom header.
Can more than one credential be uploaded to an asset?
Yes. An asset can have several credentials, and different types can be combined.
Which credentials are best to provide?
Ideally, a dedicated test user registered with a @strike.email address, since Strike automatically reads emails that arrive at that inbox (confirmation, verification, email 2FA). If that's not possible, emails can be forwarded to a @strike.email address. And if compliance doesn't allow using that domain, a username and password with any email works (this is the least recommended option, since it can get stuck on email verifications or 2FA).
Is it necessary to create the @strike.email inbox or grant access to it?
No. @strike.email inboxes are real mailboxes managed by Strike. It's only necessary to register the test user in the application using a @strike.email address (for example, [email protected]); Strike reads the emails on its own end.
Can credentials be updated after creating the asset?
Yes. The asset is edited from Details, and credentials can be updated or added whenever needed.
My application uses 2FA, how is it configured?
When adding a User & Password credential, 2FA can be configured under 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 the "Additional notes" for?
It's a field inside Advanced configuration, available for all credential types. It's worth clarifying roles and privileges, SSO, specific ways to resolve 2FA, or access to the associated email inbox there.
What happens if a credential is uploaded incorrectly?
The Pre-flight Check runs before testing starts and detects access issues. If the login fails (for example, incorrect password), it's reported so the credential can be corrected and testing can be re-run without losing coverage.