> ## 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.

# Pentest a Staging App with Cyber

> Run a scoped Cyber pentest against a staging app with two test users, read the proof behind each finding, and confirm the fix with a retest.

Before a release, you want to know whether one customer can read another customer's orders in staging. This walkthrough runs a Cyber pentest limited to the shop and order paths, with two test users, and follows one proven finding to a verified fix.

## The scenario

Your team ships a new order history page next week. Staging runs at `https://staging.shop.example.com`. The payments and admin areas belong to another team and must stay out of the test. You have two test accounts, one in each tenant, and you want proof for every issue, not a list of guesses.

## Prerequisites

* A staging deployment you're authorized to test, and access to its DNS records to verify the domain.
* Workspace admin rights, or an admin who can verify the domain for you.
* Two test accounts in the app, in different tenants.
* A [Git provider connection](https://docs.cloudthinker.io/guide/connections/github.md) with the app's repository, if you want CloudThinker to draft the fix.

The [Cyber quickstart](https://docs.cloudthinker.io/guide/security/cyber-quickstart.md) covers each setup screen in more detail.

## Walkthrough

**1. Register the app and verify the domain**

Click **Cyber** in the sidebar, then **Register an App** (or **New app** if you already have apps). Enter an **App name**, the **Application URL**, and **Web application** under **What to test**. Under **Target ownership**, click **Create DNS proof**, add the TXT record at your DNS provider, and click **Check again**.

**What you should see:** **Target ownership** shows **Verified**.

**2. Add both test users**

On **Access**, click **Add test user** twice. Give each a clear **Identity label** and **Tenant**, for example `customer-a` in `Tenant A` and `customer-b` in `Tenant B`. With two users, Cyber can test whether one can reach the other's data.

**3. Pick Safe and save without running**

On **Start**, check **Coverage status** and click **Show limited checks** to see what this run can't test. Under **Testing intensity**, select **Safe**, which sends only read requests. Click **Run later**, because setup has no scope step.

**4. Set the scope**

In the app header, click **Settings**, then **Manage scope** under **Scope**:

| List | Rules |
| - | - |
| **Include paths** | `/shop/**`, `/orders/**`, `/api/orders/**` |
| **Exclude paths** | `/admin/**`, `/api/payments/**` |

Click **Save scope**. A path that matches both lists is excluded.

**What you should see:** **Scope saved**, and the **Scope** summary counts your rules instead of reading **Full target**.

**5. Run the pentest**

Click **Run pentest** in the app header, check that **Safe** is selected, and click **Run Safe pentest**. The run can take up to three hours and uses credits. You can leave the page and check the app's **Runs** tab later.

**What you should see:** a run marked **Running**, with a live timeline of what Cyber is testing.

**6. Read the proof**

When the run shows **Success**, open the **Findings** tab. **Confirmed** lists attacks that reproduced. Open one, for example `customer-b` reading `customer-a`'s order through `/api/orders/{id}`. Under **API evidence**, you see the exact request and response that prove it, with secrets redacted.

To ask about a lead under **Needs verification**, open its **⋯** menu and choose **Chat with finding**:

```text theme={null}
Which request and identity would prove this lead? Is the same check missing on the other /api/orders endpoints in scope?
```

**7. Fix and retest**

On the confirmed finding, click **I'm working on this**, then **Create PR with agent**. In the chat that opens, say what you want:

```text theme={null}
Add the tenant ownership check to every /api/orders handler, with a test that customer-b gets 404 for customer-a's order.
```

Every change an agent makes goes through your workspace's [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md) first. On the default **Auto · Rules + AI · Ask me** mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on [Rule enforcement](https://docs.cloudthinker.io/guide/approvals/rules.md#troubleshooting) for your workspace. Choose **Manual** to approve every change yourself.

Review and test the pull request, merge it, and deploy to staging. Then click **Ready for retest** and run the pentest again.

**What you should see:** if the proof no longer works, the finding moves to **Verified fixed**. If it still works, the finding stays open.

## What made this work

* **Ownership came first.** Cyber tests only a domain you've proved you control. See [Run a pentest](https://docs.cloudthinker.io/guide/security/pentest.md).
* **Scope kept other teams safe.** Include and exclude paths kept payments and admin out of the run.
* **Two identities found the real bug.** A cross-tenant leak only shows when Cyber can sign in as two customers.
* **Every finding came with proof.** The request and response let you replay the attack yourself. See [Triage findings](https://docs.cloudthinker.io/guide/security/cyber-findings.md).
* **A retest closed the loop.** The next run, not a checkbox, moved the finding to **Verified fixed**.

## Next steps

> **[Run a pentest](https://docs.cloudthinker.io/guide/security/pentest.md)**
>
> More access options, intensities, and recurring schedules.

> **[Triage findings](https://docs.cloudthinker.io/guide/security/cyber-findings.md)**
>
> Work through proof, fixes, dismissals, and retests.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.