Adding Applications

Application Basics

Start by providing basic information about your application:

• Name - A friendly identifier for your product (e.g., "Production App", "Staging Environment")
• Description - Optional context for your team
• Environment - Select the deployment environment:

Select Attack Surfaces

Choose which interfaces of your application to test:

Most modern SaaS products have both surfaces: a web dashboard and an API that share users, data, and business logic. Enable both for complete coverage.

At least one surface must be selected. Your selection determines which configuration steps appear next.

Test Users & Credentials

Test users are defined once and shared across all surfaces. This enables consistent authorization testing across your web app and API.

Authentication Strategy:

Adding Test Users:

For pre-configured authentication, add one or more test accounts:

• Email - Where sign-in codes are sent, and the login identifier for most apps
• Username (optional) - When your login form takes a username rather than the email
• Password - Account password, if the account uses one
• Role - User role for authorization testing (e.g., "admin", "user", "viewer")

How does this account sign in?

Each account declares its login method, because guessing costs a whole scan:

If the account needs a code, you choose where we get it: a scanner mailbox we generate for you, an authenticator secret (TOTP), or a fixed test code.

Why shared users? The same credentials test both web login and API authentication, enabling cross-surface authorization testing. For example, we can verify that a "user" role can't access admin endpoints on both the web app and API.

Web Surface Configuration

This step appears if you selected Web Application.

Configure how we access your web application:

Application URL

Enter the root URL of your web app (e.g., https://app.yourcompany.com)

The host of this URL is one of the hosts you prove ownership of after saving (see the last step).

Authentication Strategy:

For most applications, Shared Users is recommended: it uses the test accounts you configured in the previous step and enables cross-surface testing.

REST API Configuration

This step appears if you selected REST API.

Configure your API for testing:

Base URL

Enter your API's root URL (e.g., https://api.yourcompany.com)

Its exact host is proven separately from the web host, including when both are under the same domain. If the URLs use the same host, one proof covers both.

OpenAPI Specification

Providing your OpenAPI spec enables deeper testing. Choose how to provide it:

Authentication Strategy:

For Static authentication, choose your auth type:

• API Key - Header name and value
• Bearer Token - JWT or access token
• OAuth 2.0 - Token URL, client ID, secret, and scope
• Basic Auth - Username and password

Rules of Engagement

Configure how aggressively we test your application:

Testing Intensity:

Test Types:

Excluded Paths

Specify paths to skip during testing (comma-separated):

• /logout - Avoid logging out test users
• /delete-account - Prevent destructive actions
• /admin/danger-zone - Skip sensitive admin functions

All testing is documented for compliance purposes. See SOC 2 Reports for details.

Schedule & Notifications

Configure when and how often we test:

Scan Frequency:

Preferred Testing Window:

Notifications:

• Email - Receive alerts when pentests complete or critical findings are discovered
• Severity Threshold - Choose to be notified for critical/high only or all findings

First Pentest:

The wizard offers two of these three options, depending on the scan frequency you chose above:

The first option is available whatever you pay with: your plan's quota, a pentest credit, or, without either, your one free preview, whose findings are listed by title, severity and endpoint but stay locked until a credit or a plan unlocks them.

Prove You Own the Domain

Saving the application creates it, but no pentest can start until you prove you control every host you entered. The wizard shows a verification panel for each host with two ways to do it:

Publish either one, then press Check now. A proof never expires, so a host proven once is proven for every application that targets it. Hosts on provider-owned suffixes such as *.vercel.app or *.run.app offer the HTTPS file only, because their DNS is not yours. Until every host is proven the application shows Ownership unverified, and Run Pentest stays disabled with the reason.