First Web Application Assessment

This guide walks you through a real web application assessment — from launching Cyberstrike to triaged vulnerability findings. We’ll test a web app with two user roles (admin and regular user) to find authorization, injection, and logic flaws.

1. Launch Cyberstrike

cyberstrike

The TUI opens with the cyberstrike primary agent loaded, ready for input.

2. Start a Session

Type anything to start a session. Describe what you’re testing:

> I'm testing https://app.example.com — it's a SaaS platform with admin and regular user roles.
  I have credentials for both. Let's find auth bypass, IDOR, injection, and business logic issues.

The agent acknowledges and may ask clarifying questions about scope, excluded areas, or additional context.

3. Rename the Session

Press Ctrl+R to rename the session to something meaningful:

example-com-web-assessment

This helps you find it later in /sessions.

4. Launch HackBrowser

Run the /hackbrowser slash command. A launch dialog opens with fields for:

• Target URL — enter https://app.example.com
• Credentials — add two: userA (admin) and userB (regular user)
• Scope — defaults to *.example.com, adjust if the API lives on a different domain
• Steps — how many pages to crawl (default 50)

Confirm the dialog. Since you defined credentials, HackBrowser opens in visible mode.

5. Login as userA

A Chromium browser window opens — this is HackBrowser, with a built-in telemetry extension that provides a UI panel overlay on every page. Log in manually as userA (the admin account).

Once logged in, press the Record button in the HackBrowser panel. This starts the AINavigator — the LLM-driven crawl session. The AI reads the page’s accessibility tree, decides which links to follow, which forms to fill, and which buttons to click, navigating the app autonomously as userA.

6. Login as userB

A second browser window opens automatically for userB (the regular user). Log in manually with userB’s credentials, then press Record in its panel.

Now HackBrowser is crawling the application with both roles. Every HTTP request is tagged with the credential that made it, so the pipeline knows which role accessed which endpoint.

7. What Happens Next

While HackBrowser crawls, the rest of the harness is already working:

Traffic capture — Every request/response pair flows into Vortex with full headers, body, and UI context (which form fields were readonly, hidden, or disabled at the moment the request fired).

Signal generation — Vortex applies rules against the captured traffic and generates signals: authentication patterns, hidden parameters, suspicious response shapes, role-specific endpoint access.

WSTG dispatch — The wstg-agent reads the signals and dispatches specialist agents. A request with a user ID in the path triggers wstg-authorization for IDOR testing. A POST with form inputs triggers wstg-input-validation for injection. A login endpoint triggers wstg-authentication.

Cross-role comparison — Because both userA and userB crawled the same app, the pipeline compares which endpoints each role reached, which UI elements were visible to each, and whether role boundaries hold when requests are replayed with the other credential.

Escalation — After specialists finish, the escalation-hunter runs across all findings to chain them — a medium IDOR combined with a low rate-limit bypass might escalate to a critical account takeover.

Triage — The triage agent independently replays HTTP evidence for each draft finding. Only findings confirmed by replay are promoted to “triaged” status. False positives are rejected. Ambiguous findings stay as drafts for your review.

8. Review Findings

Once the crawl completes and testing finishes, review the results:

Finding Format

Each finding includes:

FINDING: IDOR in User Profile API
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Severity: High
CWE: CWE-639
Description: GET /api/users/{id} returns full profile data for any user ID
             when accessed with userB credentials (regular user).
Evidence: Replayed GET /api/users/1 with userB token → 200, body contains
          admin user's email and phone number.
Status: triaged (verified by replay)
Recommendation: Enforce ownership check — users should only access their own profile.

Severity Levels

9. Export and Share

Next Steps

• Security Agents — Understand the WSTG pipeline and specialist agents
• Features — Deep-dive into HackBrowser, Vortex, Bolt, MCP
• Configuration — Customize scopes, permissions, and defaults
• Slash Commands — Full command reference