Skip to main content
In about 10 minutes of setup, plus however long your DNS change takes to appear, you register a staging app, prove you own its domain, give Cyber a test login, limit the run to the paths you choose, and start a Safe pentest. When the run finishes you open a finding and read the request and response that prove it.

​
Prerequisites

  • A staging or test deployment of a web app or API that you’re authorized to test. Don’t use production for your first run.
  • Access to the DNS records for that app’s domain, so you can add a TXT record.
  • Workspace admin rights, or an admin who can verify the domain for you. Other users see Ask a workspace admin to verify instead of the DNS proof. The admin verifies it from Cyber → Settings, or by opening this app’s Target ownership card.
  • Optional: a dedicated test account in the app (username and password). Without one, Cyber tests only what a logged-out visitor can reach.

​
Register the app

1

Open Cyber

Click Cyber in the sidebar. On a new workspace you see Nothing to test yet. Click Register an App. If you already have apps, click New app under Apps in the Cyber sidebar.
2

Enter the target

On Target, fill in:Click Continue. Target and framework can’t be changed after setup, so check them now.
The Set up a pentest step with App name, Application URL, and the Web application or API choice.

Set up a pentest: name the app, enter its URL, and choose Web application or API

3

Verify the domain

Under Target ownership, click Create DNS proof. Copy the DNS record name and TXT value, and add them as a TXT record at your DNS provider. For https://staging.shop.example.com the record looks like this:If your provider appends the zone name automatically, leave that suffix off the name. Then click Check again. A verified domain also covers its subdomains, so an admin who verifies example.com in Cyber → Settings covers staging.shop.example.com too.Success state: Target ownership shows Verified. DNS changes can take a few minutes to appear; recheck the name and value before you retry.

​
Add a test user (optional)

No test account? Click Continue on Access and skip to Choose an intensity and save.
1

Open the test user form

On Access, click Add test user.
2

Describe the account

Fill in who this user is, so Cyber knows what it should and shouldn’t see:Set Authentication method to Password, then enter Username or email, Password, and Login URL (optional) if the sign-in page isn’t easy to find from the home page. For the example shop, set it to https://staging.shop.example.com/login. Click Save login.Success state: the user appears in the list and the counter reads 1 added. Saved credentials are masked.Saving doesn’t sign in, so a saved password isn’t proof that it works. The run signs in when it starts, and if that sign-in fails the run ends as Failed instead of testing as a logged-out visitor. A Login URL must be on the same origin as the app. For a login that needs MFA or sits on a separate identity provider domain, use a Session token instead: see Add test users.
3

Skip what you don't have

Repository and API docs are optional. Skip them for this run and click Continue. Checks that needed them are listed as limited in the next step, not marked as passed.
Add a second test user from a different role or tenant. With two users, Cyber can test whether one can read the other’s data.

​
Choose an intensity and save

1

Review the summary

On Start, read the Pentest summary. Coverage status shows Ready or Ready with limitations. Click Show limited checks to see what this run can’t test and why.
2

Pick Safe

Under Testing intensity, select Safe. Its tests send only read requests (GET, HEAD, OPTIONS), so intentional writes and deletes are off for the whole run. A read can still change data if your app changes state on GET (see the intensity table). Signing in your password test user is a separate step, so it can still submit the login form at Safe. The intensity you pick here is saved as the app’s Default intensity, so the run dialog preselects it later.The UI marks Aggressive as Recommended. It adds POST, PUT and PATCH to test forms and flows, so it can create and edit test data. Save it for your second run, once you’ve checked the scope. Leave Full and Deep dive for later: they send destructive requests, including DELETE. All four are compared in Run a pentest.
3

Click Run later

Setup has no scope step, so Start pentest here would test the whole target. Click Run later instead.Success state: the saved app opens with no run.

​
Set the scope

1

Open Manage scope

In the app header, click Settings. Under Scope, click Manage scope.
2

Add include and exclude paths

Add the paths this first run may test under Include paths, and anything that must stay off-limits under Exclude paths. For the example shop:** matches any depth, and a path that matches both lists is excluded. Your test user’s Login URL must match an include rule, or the sign-in fails with Login could not stay within its safety boundary and the run ends as Failed. That’s why /login is in the example. Click Save scope. Pattern rules are in Set scope and context.Success state: you see Scope saved, and the Scope summary counts your include and exclude rules instead of reading Full target.

​
Start the pentest

1

Open the run dialog

In the app header, click Run pentest. Check that Safe is selected under the testing intensity cards.
2

Launch

Click Run Safe pentest.Success state: the app’s run workbench opens and the run shows Running, with a live timeline of what Cyber is testing.
Run history, live timeline, findings, and discovered attack surface.
You can leave the page. The run continues for up to three hours and uses credits (see Usage). There’s no notification when it finishes, so check back on the app’s Runs tab. If your password test user can’t sign in, the run ends as Failed, so check the Runs tab for that too. Only a Session token that fails its check as the run starts also sends a Pentest run blocked notification. To cancel, click Stop run. A stopped run can’t be resumed, but findings already saved remain.

​
Read the findings

1

Open Findings

When the run shows Success, open the app’s Findings tab. The Confirmed tab is selected by default: these are attacks that reproduced.
2

Open a finding

Click a finding. The detail page shows severity, the OWASP category, the impact, how to fix it, and the evidence: the exact Request and Response that prove the issue.
3

Decide what to do

For a real issue, choose Create PR with agent to have CloudThinker draft a fix, or track it on the board. The fix chat uses the repositories attached to the app. This quickstart skipped that, so attach one first: see Connect a Git provider. For a non-issue, dismiss it with a reason. Findings under Needs verification are leads Cyber couldn’t prove yet.
A run with no confirmed findings doesn’t mean the app is secure. Check the limited checks from the Start step: anything Cyber couldn’t reach wasn’t tested.

​
Troubleshooting

For every Cyber problem in one place, see Cyber troubleshooting.
Compare the TXT record you published with the DNS record name and TXT value shown. A common cause is a provider that appends the zone name, so the domain appears twice in the record name. Remove the duplicate, wait a few minutes, and click Check again.
The test user couldn’t sign in. Saving a password doesn’t test it, so the first check happens when the run starts, and a failed sign-in stops the run instead of testing as a logged-out visitor. Update the password or Login URL in the app’s Settings under Test identities, and run again. For MFA or a login on another domain, use a Session token.
Configure CAPTCHA options on the test user before the run. See Handle CAPTCHA logins.

​
Next steps

Walkthrough: follow one proven finding from a scoped staging pentest to a verified fix in Pentest a staging app with Cyber.

Cyber troubleshooting

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

Triage findings

Work through proof, fixes, and retests

Run a pentest

Add scope rules, more access, and a schedule