DEV Community

Mohammad NaVeEd
Mohammad NaVeEd

Posted on

I built a browser-based fuzzer and here's how I solved the CORS problem

Web fuzzing tools have always lived in the terminal. I wanted to change that, so I built FFUF — a browser-based fuzzer that actually works on external targets.

The CORS wall

The first problem with any browser-based security tool is CORS. If you try to fetch() an external URL from browser JavaScript, you can send the request but you can't read the response. The browser blocks it. For a fuzzer, this is fatal — you need to see status codes.

The fix is a server-side proxy. Instead of the browser calling the target directly, it calls your own API endpoint, which makes the real HTTP request server-side and returns the full result.

In Next.js this is a single API route:

Browser → POST /api/proxy → Target server → real response → Browser

The proxy captures status, headers, body size, redirect location, content type, and response time. The browser never touches the target directly.

The fuzzing engine

The core loop is simple. Build a wordlist. For each entry, replace FUZZ in the URL or request body with that entry, call the proxy, get the real response, apply filters, show results.

The tricky part was React state batching. When you run 3 concurrent requests per burst, they all try to call setResults() at the same time. React batches these and you lose results. The fix is collecting each burst's results into a local array and doing a single state update after the burst completes.

What I built

Four fuzzing modes — directory discovery, IDOR number range testing, POST body fuzzing, and brute force. A 2,800+ path built-in wordlist. Real-time streaming results with status-based filtering. CSV export.

Live at ffuf.codewithneo.com. Would love feedback from other devs, especially on the proxy architecture.

Top comments (0)