HackBrowser

The most damaging class of web vulnerabilities — broken access control — is also the hardest to find automatically. A scanner can fire payloads, but it can't answer the question that actually matters: can User A see User B's data? That question requires two authenticated identities, real application state, and something that knows what each identity is supposed to reach. Scanners have none of these. HackBrowser exists to solve that.

The problem

Modern apps are authenticated, stateful, and role-based. The critical bugs live inside the session: one user reading another user's order (IDOR/BOLA), a regular user calling an admin endpoint (BFLA), a guest escalating to a paid tier. These aren't pattern-match problems — they're identity-relative. You only see them when you compare what this identity got against what that identity should have been allowed to get.

Traditional tools fail here because they operate as a single anonymous or single-session client. A human pentester can do it — by logging in as both roles and comparing — but it's slow, manual, and doesn't scale past a handful of endpoints.

How HackBrowser works

HackBrowser launches isolated Chrome profiles — each with its own cookie jar, its own session, its own identity. One tab is admin, another is regular user, another is guest. Each profile loads a browser extension that captures every request/response and tags it with the credential label. All profiles feed one shared CyberStrike session.

The traffic from all profiles lands in Vortex, which now has something no scanner has: the same application, seen through multiple identities simultaneously. From that multi-identity corpus, Vortex builds two deterministic structures:

• Object inventory — every data object (order:42, user:7, invoice:1001) and which roles accessed it. An object reached under more than one role is an IDOR/BOLA candidate.
• Function inventory — every endpoint (GET /api/orders/id, POST /admin/users) and which roles called it. A function called by more than one role, where one role found it only through replay, is a BFLA surface.

These aren't guesses. They're computed directly from the traffic graph. The distinction between "crawl" (the role found this link in the UI) and "forced" (only seen via replay) eliminates the false positives that make access-control testing noisy.

Confirm, don't guess

The authorization specialist agent receives these cross-role leads and confirms each one by credential-swap replay: take the request User A made, strip User A's session, drop in User B's credential, replay it, and compare the responses. A 200 that returns another user's data is proof. A 403 means the control holds. Every finding ships with the original request, the swapped request, and the response diff.

The full pipeline:

1. Capture — N profiles browse the app, each as a different role
2. Inventory — Vortex computes the object/function graph across identities
3. Surface leads — cross-role objects and functions are flagged deterministically
4. Confirm — the authorization agent replays each lead with swapped credentials
5. Prove — findings carry request/response evidence; unconfirmed leads stay drafts

Why a real browser

A proxy-based approach can do step 4, but it can't do steps 1–2 correctly for modern single-page apps. SPAs don't expose their routes in HTTP — they're compiled into JavaScript bundles, rendered client-side, and gated by client-side guards that never produce a request until the UI path is followed.

HackBrowser uses a real browser with a real extension that sees what the user sees — including dynamically rendered links, SPA route transitions, and client-side auth state — and feeds all of it into the traffic corpus. The profiles are fully isolated, so credentials can't leak between roles. The extension captures the actual requests the browser made — no cert pinning issues, no HSTS complications, no missing client-side-only traffic.