Skip to main content
A pentest is a run where CloudThinker attacks one of your apps the way an attacker would, within limits you set, and records proof for every problem it confirms. This page covers every setup option; for a minimal first run, use the Cyber quickstart.

​
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.
  • Optional: dedicated test accounts, an OpenAPI spec or Postman collection, and a Git connection 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.
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.
4

Review and start

On Start, check the Pentest summary and Coverage status. Click Show limited checks to see what the current inputs can’t test. Choose a Testing intensity, then click Start pentest, or Run later to save the app without running.Setup has no scope step, so Start pentest covers the whole target. For a first run, pick Safe, click Run later, then set include and exclude paths in Scope under the app’s Settings before you run. The Cyber quickstart walks through this.Success state: Start pentest 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 pentest dialog. All three open the same form: describe the user (Identity label, Identity description, Persona or role, Tenant), then pick an Authentication method. For Agent creates new account, write instructions that name the roles to create, use <generated_username> and <generated_password> for the credentials, and say what proves the login worked:
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.
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.
Test user form with its details and password login.

​
Set scope and context

Open the app and click Settings. Target and framework are read-only here. Everything else is editable. Path rules are globs matched against the whole path:
  • 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.

​
Choose access and intensity

The access level comes from what you provided, not from a setting: Intensity decides what the run may do. This is the reference table for every Cyber page: 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.
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 pentest. 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 pentest (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).Success state: a run opens the workbench with status Running. A schedule appears in the app’s Settings as Enabled.
Run pentest dialog with intensity and run controls.
To change a schedule, use Edit schedule in the app’s Settings. Pausing keeps its configuration. An app runs one pentest at a time.
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 attack 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 Pentest 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 attack surface.

​
Troubleshooting

For every Cyber problem in one place, see Cyber troubleshooting.
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.
A saved login didn’t work. A session token is re-checked twice: when you open Run pentest, 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.
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.
It compares against the last successful run. Complete one Whole codebase run first.

​
Next steps

Cyber troubleshooting

Every Cyber problem in one place, with cause, check and fix

Triage findings

Read the proof, fix, and retest

Cyber reports

Export selected findings or a run’s assessment

Run a Code Audit

Audit the source code behind the app you just tested