> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt > Use this file to discover all available pages before exploring further. # Run a Security Test > Set up a test target, verify its domain, add test users and scope, then run it now or on a schedule and track the results. A test run is a DAST scan of one of your running apps: CloudThinker tests it within limits you set and records request and response proof for every problem it confirms. This page covers every setup option; for a minimal first run, use the [Cyber quickstart](https://docs.cloudthinker.io/guide/security/cyber-quickstart.md). ## Prerequisites * An app you're authorized to test, reachable at a domain URL. Use staging for anything above **Safe** intensity. * Access to the domain's DNS records, and workspace admin rights to verify the domain. * Credits for the run. Every run uses them, and Deep dive uses the most. See [Usage](https://docs.cloudthinker.io/guide/billing/usage.md). * Optional: dedicated test accounts, an OpenAPI spec or Postman collection, and a [Git connection](https://docs.cloudthinker.io/guide/connections/github.md) for white-box testing. ## Register the app **1. Set the target** Open **Cyber** and click **New app** under **Apps** (or **Register an App** on an empty workspace). On **Target**, enter **App name** and **Application URL**, then choose **Web application** or **API** under **What to test**. Click **Continue**. That choice decides which OWASP categories the coverage report measures. You can't combine them or change them later; create a second app to test the same host as an API. ![App name, Application URL, and Web or API coverage.](https://mintcdn.com/cloudthinker/YUtBQCA-74Ac7wGh/images/security/cyber/02-test-target.png?fit=max\&auto=format\&n=YUtBQCA-74Ac7wGh\&q=85\&s=5cb73b9c91f3172933e05ad5f8716148) **2. Verify the domain** Under **Target ownership**, click **Create DNS proof**. Add the shown **DNS record name** and **TXT value** as a TXT record at your DNS provider, then click **Check again**. If your provider appends the zone name, leave that suffix off. **Success state:** **Target ownership** shows **Verified**. If the host is covered by a domain you already verified, the card says **Proof reused from** that domain and no new record is needed. **3. Add access** On **Access**, add test users, a repository, and API docs. All three are optional. See the sections below for each. ![Optional test users, source code, and API documentation.](https://mintcdn.com/cloudthinker/YUtBQCA-74Ac7wGh/images/security/cyber/03-test-access.png?fit=max\&auto=format\&n=YUtBQCA-74Ac7wGh\&q=85\&s=e88123ad92a4a6c58421bf09b1845858) **4. Review and start** On **Start**, check the **Test summary** and **Coverage status**. Click **Show limited checks** to see what the current inputs can't test. Choose a **Testing intensity**, then click **Start test**, or **Run later** to save the app without running. Setup has no scope step, so **Start test** covers the whole target. For a first run, pick **Safe**, click **Run later**, then set include and exclude paths in [Scope](#set-scope-and-context) under the app's **Settings** before you run. The [Cyber quickstart](https://docs.cloudthinker.io/guide/security/cyber-quickstart.md) walks through this. **Success state:** **Start test** opens the run workbench. **Run later** opens the saved app with no run. You can manage verified domains for the whole workspace from **Cyber → Settings**. Verifying a domain authorizes testing on it. It doesn't widen any app's scope. ## Add test users Test users let Cyber reach pages behind a login and check authorization: can user A see user B's data? The button reads **Add test user** during setup, **Add authentication** in the app's **Settings** under **Test identities**, and **Add auth** in the **Run test** dialog. All three open the same form: describe the user (**Identity label**, **Identity description**, **Persona or role**, **Tenant**), then pick an **Authentication method**. | Method | What you enter | How it's checked | | - | - | - | | **Password** | **Username or email**, **Password**, **Login URL (optional)** | Saved without signing in. The run signs in when it starts, and a failed sign-in ends the run as **Failed**. See [Handle CAPTCHA logins](https://docs.cloudthinker.io/guide/security/captcha.md#configure-the-login) | | **Session token** | A signed-in `GET` request copied as cURL from your browser's Network panel | **Verify and attach** sends the request once and saves it only if it succeeds. CloudThinker re-checks it twice more: when you open **Run test**, and again as the run starts | | **Long-lived token** | One header name and value per row, for example name `Authorization`, value `Bearer `. A blank first name defaults to `Authorization`. | Saved without a check. The run reports if access is rejected. | | **Agent creates new account** | **Instructions** for creating users through a signup page or admin API | Each manual run creates fresh users and reports whether signup and login worked. Signup creates real accounts in your app, so pick **Aggressive** or above for this method | For **Agent creates new account**, write instructions that name the roles to create, use `` and `` for the credentials, and say what proves the login worked: ```text theme={null} Sign up at /register with and . Create one "member" and one "admin" user. Login succeeded when the page shows "Welcome back" and the URL is /dashboard. ``` The instructions are stored encrypted and never shown again. To change them, open the account in the app's **Settings** under **Test identities** and enter new instructions, which replace the saved ones. Signup that needs an email or SMS code isn't supported. Scheduled runs sign in only with **Long-lived token** users, because only those are safe to reuse unattended: sessions expire, and password and agent-created logins aren't used on schedules. A schedule never switches itself off. If the token has been deleted when an occurrence fires, that occurrence ends as **Failed** and you're notified, and the next one signs in again as soon as a working token is saved. Without a long-lived token, a schedule runs without signing in as your test users, so it can't test or recheck anything behind the login. Run those checks manually, or add a long-lived token user. > [!TIP] > > Add two users from different roles or tenants. With two of them, Cyber can test whether one user can read or change the other's data. A copied cURL request contains a live session. Treat it as a password and paste it only into this form. If the login uses a CAPTCHA, set it up first: see [Handle CAPTCHA logins](https://docs.cloudthinker.io/guide/security/captcha.md). ![Test user form with its details and password login.](https://mintcdn.com/cloudthinker/_u5eRuTpYujlERGZ/images/security/cyber/13-test-user-credentials.png?fit=max\&auto=format\&n=_u5eRuTpYujlERGZ\&q=85\&s=43b85f6db43decd66878b1f2fd2b72e6) ## Set scope and context Open the app and click **Settings**. Target and framework are read-only here. Everything else is editable. | Section | What to set | | - | - | | **Scope** | Click **Manage scope** to set **Include paths**, **Exclude paths**, and **Page asset origins**, then click **Save scope**. With no rules, the summary reads **Full target**. | | **Context files** | An OpenAPI spec, Postman collection, runbook, architecture note, or other document. These help Cyber find endpoints it can't discover by crawling. | | **Repositories** | A connected repository and branch. This makes the run white-box. | | **Test identities** | The same methods as in setup | | **Schedule** | Recurring runs you can edit, pause, or delete | | **Default intensity** | The intensity preselected for later runs | Path rules are globs matched against the whole path: | Pattern | Matches | Doesn't match | | - | - | - | | `/api/*` | `/api/users` (one segment) | `/api/users/42` | | `/api/**` | `/api/users`, `/api/users/42` (any depth) | `/api` itself | | `/admin/**` in **Exclude paths** | Everything under `/admin/` | `/administrator` | * **Exclude always wins.** A path that matches both lists is off-limits. * **No include rules means the whole target.** Every path on the app's host is in scope until you add one. * **Other hosts stay out.** **Page asset origins** takes exact HTTPS origins, such as `https://cdn.example.com`, and only lets pages load scripts, styles, images, and fonts from them. Navigation and active requests stay on your target. * Each list holds up to 100 rules of up to 100 characters. ![Included and excluded paths for a demo API.](https://mintcdn.com/cloudthinker/YUtBQCA-74Ac7wGh/images/security/cyber/06-test-scope.png?fit=max\&auto=format\&n=YUtBQCA-74Ac7wGh\&q=85\&s=68ebbe69da0796713606b70ac94636f2) ## Choose access and intensity The access level comes from what you provided, not from a setting: | Access level | You provided | | - | - | | **Black-box** | The URL only | | **Gray-box** | The URL plus test users | | **White-box** | The URL plus a repository, with or without test users | Intensity decides what the run may do. This is the reference table for every Cyber page: | Intensity | What it does | Run it against | | - | - | - | | **Safe** | Explores routes and responses with read requests only (`GET`, `HEAD`, `OPTIONS`). Writes and deletes are off. | Your first run on a new app, and any environment where data must not change | | **Aggressive** (the UI marks it **Recommended**) | Adds `POST`, `PUT` and `PATCH` to test forms and business flows. Can create and edit test data. `DELETE` stays off. | Staging, once a Safe run has confirmed scope and logins | | **Full** | Adds `DELETE` and tests high-impact actions, including changing and deleting in-scope data. Asks you to confirm first. | Staging with disposable data only | | **Deep dive** | Everything Full does, over several passes that follow connected multi-step flaws. Uses the most time and credits. Asks you to confirm first. | Staging with disposable data only. See [Deep dive testing](https://docs.cloudthinker.io/guide/security/deep-dive-testing.md) | Safe avoids intentional data changes, but a read request can still change data if your app changes state on `GET`. Set include paths before a first run either way. The sign-in step for a **Password** test user is separate from the intensity limits, so it can submit your login form at any intensity, Safe included. > [!WARNING] > > **Full** and **Deep dive** send destructive requests, including `DELETE`, to the target. Before they start, a dialog asks you to confirm. Use a disposable environment and test accounts; data inside the saved scope can be permanently changed or deleted. ## Run now or on a schedule **1. Open the run dialog** On the app page, click **Run test**. The dialog shows the app's setup facts and any blocker, such as **Domain verification required**. **2. Pick intensity and scan scope** Choose an intensity. On a white-box app, also set **Scan scope**: **Changes only** tests the commits on each attached repository's saved branch since the commit the last successful run recorded. **Whole codebase** tests everything. The first run must use **Whole codebase**, and a branch with no new commits gets a whole-codebase pass. **3. Run or schedule** Click **Run Safe test** (the label follows the intensity) to start now. To repeat it, click **Schedule…** instead and pick **Daily**, **Weekly**, **Monthly**, **No Repeat** (one time), or **Custom** (a cron expression). Times are in your browser's local time zone. You can also set an expiration date. Click **Schedule** to save. For **Full** or **Deep dive**, a dialog asks you to confirm the schedule. Schedules sign in only with **Long-lived token** test users (see [Add test users](#add-test-users)). **Success state:** a run opens the workbench with status **Running**. A schedule appears in the app's **Settings** as **Enabled**. ![Run test dialog with intensity and run controls.](https://mintcdn.com/cloudthinker/YUtBQCA-74Ac7wGh/images/security/cyber/07-run-test.png?fit=max\&auto=format\&n=YUtBQCA-74Ac7wGh\&q=85\&s=3f946c93f57d3b261ed2aa51ed1877cf) To change a schedule, use **Edit schedule** in the app's **Settings**. Pausing keeps its configuration. An app runs one test at a time. > [!WARNING] > > A scheduled **Full** or **Deep dive** run sends destructive requests each time it fires, with nobody confirming that occurrence. Schedule them only against staging with disposable data and tight scope. ## Watch the run The workbench shows run history, findings as they're saved, and the app surface Cyber discovered. Each run has two tabs: **Timeline** for live activity, and **Report** for the finished report, which lists what the run couldn't test, such as areas behind a failed login. A run ends as **Success**, **Failed**, or **Stopped**. There's no notification when a run finishes, so check the **Runs** tab. If a **Session token** fails its check as the run starts, the run ends as **Failed** without testing anything, and you get a **Test run blocked** notification. A **Password** sign-in that fails also ends the run as **Failed**, with no notification. A **Long-lived token** isn't checked first, so a token your app rejects doesn't stop the run: it keeps going and its report lists what it couldn't test. Update the login in the app's **Settings** under **Test identities** and start a new run. **Stop run** cancels the run, and it can't be resumed. Findings saved so far stay. A failed or stopped run is an incomplete test, so don't read its results as a clean bill of health. ![Run history, timeline, findings, and discovered app surface.](https://mintcdn.com/cloudthinker/_u5eRuTpYujlERGZ/images/security/cyber/08-run-workbench.png?fit=max\&auto=format\&n=_u5eRuTpYujlERGZ\&q=85\&s=f6006424c4888f08190fe3e16f2e3de2) ## Troubleshooting For every Cyber problem in one place, see [Cyber troubleshooting](https://docs.cloudthinker.io/guide/security/cyber-troubleshooting.md). > **Run test is blocked with Domain verification required** > > The domain isn't verified yet, or the TXT check failed. Compare your DNS record with the **DNS record name** and **TXT value** in **Target ownership**, fix any duplicated zone suffix, and click **Check again**. If you aren't a workspace admin, ask one to verify it. > **The run is blocked or fails at sign-in** > > A saved login didn't work. A session token is re-checked twice: when you open **Run test**, where the dialog shows **A saved login no longer works** and won't let you launch the run, and again as the run starts, where a failure ends the run as **Failed**. A password is never checked in advance — it's first tried when the run starts, and a failed sign-in ends the run as **Failed**. Update the password, refresh the cURL session, or replace the token in the app's **Settings** under **Test identities**, and run again. > **Coverage shows limited checks** > > A check needed something you didn't provide: a second role, a tenant, a repository, or API docs. Add it and rerun. Limited checks aren't passed checks. > **Changes only is locked** > > It compares against the last successful run. Complete one **Whole codebase** run first. ## Next steps > **[Cyber troubleshooting](https://docs.cloudthinker.io/guide/security/cyber-troubleshooting.md)** > > Every Cyber problem in one place, with cause, check and fix > **[Triage findings](https://docs.cloudthinker.io/guide/security/cyber-findings.md)** > > Read the proof, fix, and retest > **[Cyber reports](https://docs.cloudthinker.io/guide/security/cyber-reports.md)** > > Export selected findings or a run's assessment > **[Run a Code Audit](https://docs.cloudthinker.io/guide/security/code-audit.md)** > > Audit the source code behind the app you just tested This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.