You configure a web application scan in Vooki Pro through a six-step wizard. It opens in its own tab, so you can leave it half-finished to record a browser session or add an auth profile, then come back without losing your place.

Only scan applications you own or have written permission to test. An active scan sends real attack payloads and can create, change or delete data. Point your first scan at a staging environment.

Before you start: create the application

1. Open Applications in the sidebar and click New application.
2. Set Type to Web, then enter a Name (for example Acme staging) and the base URL (for example https://staging.example.com).
3. Pick the Environment: dev, staging or prod. Environments are colour-coded, so you never mistake a production target for a sandbox.
4. Click Save, then click Scan on the new row.

For a one-off test you can skip this and paste a URL straight into the wizard.

Step 1: Target and host scope

Pick the application, then decide which hosts the scan may touch:

• Same Host: only the exact host you entered. This is the safe default.
• Same Domain: the domain and its subdomains.
• Custom Hosts: only the hosts you tick in the list.
• All Detected Hosts: every host the page talked to, including third parties. Avoid this unless you have a documented reason, because it can send payloads to services you do not own.

Vooki Pro loads the start URL once in a headless browser and lists every host the page contacted, labelled as app, API, auth, CDN or third party. Use Add Host for anything it missed.

Step 2: Discovery

A scanner can only test the URLs it finds, so this step affects results more than any other.

• Quick scan: only the URL you entered.
• Crawl website: follows links from the start URL. Best for traditional multi-page sites.
• Use recording: replays a browser recording so the scanner walks exactly the screens you walked.
• Hybrid: replays a recording, then crawls outward from it. Best for single-page apps.

Keep Discover background / API requests ticked so the scanner also sees the XHR and fetch calls your JavaScript makes. Use Discovery exclude for URLs such as */logout. See Crawling a website for every discovery setting.

Step 3: Authentication

Without authentication, the scanner reaches the login page and little else.

• Use a saved auth profile: bearer token, basic auth, API key, cookie, form login or OAuth2 client credentials.
• Manual: paste a token, header or cookie for a one-off run.
• Login via recording (recommended): reuse the cookies captured when you logged in yourself. This works for SSO.

Enable Auto re-login if session expires during scan on long scans. Otherwise, everything after the session timeout is silently tested as logged out.

Step 4: Policy

The policy decides which checks run:

• Quick: security headers and version fingerprinting. A fast first look.
• Standard: OWASP Top 10 essentials. A good choice for regular testing.
• Focused: high-signal injection families plus XSS and headers.
• Deep: core categories including SSRF, SSTI and IDOR.
• Default: every check in the catalogue. The most thorough and the slowest.

On the same step, set Requests / second, Concurrency and Delay to throttle fragile targets. Use Attack exclude for logout, delete and download URLs: they are still mapped, but they never receive a payload.

Step 5: Schedule

Choose Run now, or repeat the scan daily, weekly, monthly or on a cron expression. See Scheduled scans.

Step 6: Review and launch

Check the summary, then click Launch scan. The scan runs in the background while you keep working. Export Config saves the whole setup as JSON for the CLI.

After the scan

Each scan opens in its own tab with Overview, Findings, Sitemap, Scope and Logs views. Check the coverage panel first. If only a handful of URLs were discovered on a large app, fix discovery and rescan before trusting the result. Then see Working with findings and retest.

Full reference: How to run a web application scan (docs).