Everything here assumes you've already got the extension built and a dashboard running somewhere — local or deployed. If you haven't, start with Getting Started below.
Two pieces, built separately:
The dashboard needs to exist first — the extension talks to it, not the other way around. Deploy or run the dashboard, create an account, then set up the extension to point at it.
From the extension/ folder:
npm install npm run build
Then in Chrome: chrome://extensions → enable Developer Mode → Load unpacked → pick the dist folder,
not the extension folder itself.
Open the extension's options page (right-click the toolbar icon → Options), and fill in your dashboard's URL and an API key. You'll generate that key from the dashboard in a minute — see below.
Once connected, the popup shows the payload library. It also reads whatever page you're on — forms, URL params, file params — and bumps the relevant categories to the top instead of making you scroll through all ten.
Register an account, then go to Settings. Two things need to happen before you can generate an API key: fill in your full name under Personal Information, and verify your email (click "Get verification link" — it's rate-limited to one request per 90 seconds, so don't mash it).
Once both are done, generate a key under API Keys and paste it into the extension's options page alongside the dashboard's URL. Hit "Test connection" there to confirm it's actually talking.
Everything in the dashboard is organized under Programs — a program is a bug bounty program or a private engagement. Targets, recon results, and findings all belong to a program.
On a program's page, add a target domain, then run Subdomain recon (certificate-transparency lookups against crt.sh) or Fingerprint (reads response headers, cookies, and markup signatures to guess the stack — WordPress, Next.js, Laravel, that kind of thing).
Worth being clear about: recon results aren't findings. They're reference material. A finding is something you've actually flagged — either from the dashboard's "+ New finding" button, or from the extension's popup, where "Flag as finding" captures the payload you used and the page you were on.
By default, findings and recon from the extension land in your most recently created program. If you're running more than one engagement at once, set a specific program in the extension's options page instead of relying on that guess.
Every program has a "Download report" button that generates a PDF — cover page, summary by severity, then one page per finding with steps to reproduce, the payload used, and an impact section you fill in before submitting. Shaped for HackerOne or Bugcrowd, but it's just a PDF — attach it wherever you need to.
The extension talks to the dashboard over a small API, authenticated with Authorization: Bearer <api key>.
All under /api/extension/*:
GET /api/extension/ping Verifies the key. Returns the account email if valid.
GET /api/extension/programs Lists your programs — powers the extension's program picker.
POST /api/extension/findings Body: title, category, payloadUsed?, pageUrl?, notes?, programId?.
GET /api/extension/recon/subdomains?domain=&programId= Passive subdomain harvest via crt.sh.
GET /api/extension/recon/fingerprint?url=&programId= Tech fingerprint of a single URL.
No, on purpose. It's a reference tool, not a gatekeeper — the scope is your call, not the software's.
Yes — that's the only way to run it. You'll need a Neon Postgres database and, optionally, a Brevo account for email verification.
That needs a persistent worker, not a serverless function — a browser extension and a Vercel deployment can't run nmap. It's a deliberate scope decision, not an oversight.
It lives in whatever Neon database you point the dashboard at. Nobody else's Redline instance can see it.