Let’s get you in.

Your first scan

1. Open rootscan. Sign in and add the application you want to test.
2. Set a scope. Identify allowed hosts, environments, and paths. Keep unrelated third-party services outside it.
3. Add a test identity. Use a dedicated account with synthetic data. Add another account if you want to test roles or tenant isolation.
4. Review and run. Confirm the scope, then start the scan. rootscan explores the app and validates findings.
5. Read the evidence. Prioritize by impact, apply a fix, and retest the affected route.

Scope & authorization

Only test applications you own or have explicit permission to test. A public URL is not permission.

Staging is a good place to begin. Use synthetic data and exclude destructive flows such as deleting accounts, issuing refunds, sending real messages, or charging a payment method.

• List the allowed domains and API hosts.
• Identify paths and actions that must not be tested.
• Agree on a testing window if other people depend on the environment.
• Keep the scope available for your team’s review.

Connect a login

Authenticated coverage starts with a session rootscan can use. Prepare a dedicated test account and follow the connection flow in the app.

The product is designed to capture a real session and refresh it during testing. Exact handling of SSO, MFA, and short-lived sessions depends on the supported connector. Check that the session still works before running a full scan.

A useful preflight check

• The account can open the pages you want tested.
• Its role is clearly documented.
• It has test records to read and update where allowed.
• It can be revoked when the engagement is finished.

Test across identities

A single session shows what one user can do. Two identities help reveal what they should not be able to do.

For a multi-tenant app, create one member in Workspace A and another in Workspace B. Seed a small amount of different test data in each. rootscan can then check whether a request from one identity crosses the boundary.

Workspace A  →  member-a@your-test-domain
Workspace B  →  member-b@your-test-domain

Expected: each member can read only their own records.

To test role boundaries, include two different roles in the same test workspace, such as a member and an admin.

Read a finding

A useful finding explains what happened and how to check it yourself. Start with the impact summary, then inspect the identity, request, response, and reproduction steps.

• Severity: a CVSS score and vector describe the assessed impact and exploit conditions.
• Evidence: a transcript demonstrates the behavior under the tested conditions.
• Fix: a concrete remediation direction for your team to review.
• Retest: a follow-up check after the change.

Retest & monitor

Fixing one request is a good start. Test related paths, roles, and tenants too.

Once a fix is deployed, rerun the original check. A blocked response alone is not enough: verify that the intended user can still perform the legitimate action. Continuous plans keep checking as the app changes.

Source code & APIs

A source repository, code archive, or API specification can give rootscan more context about routes and how they are implemented.

Before sharing source, remove unnecessary files and review secrets. For APIs, prepare a current OpenAPI specification or the API material supported by the app, with a dedicated test credential.

The goal is to connect the code path to observable behavior in an authorized environment.

Something not connecting?

The session expires

Check the account is active and the session can be refreshed. SSO and MFA may require another connection step. Reconnect the test identity before retrying.

The app cannot be reached

Check the exact hostname, network restrictions, and test environment availability. Confirm connectivity before widening a scope or changing firewall rules.

The scan sees very little

Check that the identity has access to real test workflows and that the scope includes the related API hosts. An empty test account often has fewer paths to explore.