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

Mohammad NaVeEd — Sat, 22 Aug 2026 15:28:48 +0000

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.

A free, 100% browser-based cURL tool that runs entirely in your client

Mohammad NaVeEd — Mon, 01 Jun 2026 11:10:37 +0000

Hi everyone,

I built curl.codewithneo.com because I was tired of switching back and forth between my terminal and the browser just to test quick API requests, format payloads, or debug headers.

While there are plenty of web-based HTTP clients out there, a lot of them send your data through their own backend servers. As a developer/security researcher, sending API keys, bearer tokens, or sensitive payloads through a third-party server always felt like a massive security risk.

So I built a completely client-side alternative.

Key Features
100% Browser-Based: All requests are executed directly from your browser. Your sensitive API keys, tokens, and endpoints never touch an external backend server.

Completely Free: No paywalls, no "premium tiers" for basic HTTP methods, and no sign-ups required.

Clean UI: Fast, lightweight, and built to let you drop in a cURL command or construct a request in seconds.

Why use this over a local terminal?
Sometimes you just want a clean visual interface to inspect response headers, pretty-print massive JSON payloads, or quickly tweak a request without messing up your terminal history.

I’d love to get your feedback on it. What features should I add next? If you encounter any CORS issues or have ideas for improvements, let me know!

Check it out here: ncurl

DEV Community: Mohammad NaVeEd

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

The CORS wall

The fuzzing engine

What I built

A free, 100% browser-based cURL tool that runs entirely in your client