I built Burp Suite in Rust

An intercepting proxy is not a complicated artifact. It terminates TLS, presents itself as the trusted CA to the client, replays modified requests to the upstream, and exposes a request/response history to a UI. Burp Suite Professional packages that core with a scanner, an extender API, collaborator infrastructure, and a paid license. The open-source alternative I built - call it the project, the binary is not the point - replicates the proxy core, the repeater, the intruder-equivalent fuzzer, and the passive scanner. It does not replicate Collaborator, the active scanner’s payload research depth, or the BApp ecosystem. The gap matters for vulnerability research. This is what the project does, where it falls short, and how that maps to the actual work of finding and weaponising web bugs.

The proxy core is built on a Rust async runtime with rustls for TLS termination. mitmproxy’s addon model was the reference point for the interception loop, not the codebase. The CA cert generation is standard - an RSA-3072 root, ephemeral leaf certs signed per-host on connection establishment, cached for the session. SNI is honoured. HTTP/2 is decoded into the same internal request representation as HTTP/1.1, which means H2-specific bugs like request smuggling via header normalisation (CVE-2023-44487 class issues at the protocol layer, not the DoS amplification) are visible in the flow viewer. WebSockets are framed and exposed. HTTP/3 over QUIC is not implemented. That is a gap. Cloudflare-fronted targets increasingly negotiate H3 by default, and the proxy currently forces fallback to H2 by advertising only h2 and http/1.1 in ALPN. The target still talks to you, but you are not seeing the protocol the real client uses. For research on H3-specific parsing differentials, the project is the wrong tool.

The repeater is a thin wrapper over the proxy’s send primitive. It diffs responses by length, status, and a normalised body hash. The intruder-equivalent - internally called the fuzzer - runs payload sets against marked positions in a template request. Sniper, battering ram, pitchfork, cluster bomb modes are implemented under different names. Concurrency is configurable up to 256 in-flight requests per worker, which is enough to saturate most targets and get you rate-limited fast. There is no built-in throttling that respects target health. That is by design for a research tool. It is the wrong default for engagements against production estates and the documentation says so.

The passive scanner is where the project’s depth diverges most sharply from Burp Pro. Passive checks run against every flow that transits the proxy. Implemented checks cover the obvious surface - reflected input in response bodies without encoding context awareness, missing security headers with CWE-693 references, cookies without Secure or HttpOnly attributes, JWTs with alg none or HS256 with weak keys, CORS misconfigurations including the null origin and credentialed wildcard cases, and source map exposure. The check engine maps each finding to CWE and, where the bug class corresponds to a known technique, to a MITRE ATT&CK ID - T1190 for exploitable web app vulnerabilities reachable pre-auth, T1552.001 for credential material exposed in responses.

The active scanner is partial. SQL injection detection runs time-based and boolean-based checks for MySQL, PostgreSQL, MSSQL, and Oracle dialects. Error-based detection keys on a curated list of dialect-specific error strings. There is no DBMS fingerprinting depth comparable to sqlmap, and no second-order injection support. Command injection checks fire on time-based blind primitives using sleep, ping, and timeout, with OS detection inferred from the working primitive. SSRF detection requires an out-of-band component, which is where Collaborator-equivalence becomes the critical gap. The project ships a self-hostable interaction server that takes a DNS zone and an HTTP listener. You run it on infrastructure you control. It produces interaction events with source IP, protocol, timestamp, and request body for HTTP. It does not handle SMTP, FTP, LDAP, or SMB callbacks. PortSwigger’s Collaborator handles all of them. For research into SSRF chains that pivot through non-HTTP protocols - Gopher-based Redis abuse, SMB credential capture against Windows-fronted targets - the project’s interaction server will not see the callback. The bug exists. You will not.

The extender model is a WebAssembly runtime. Extensions are compiled to wasm32-wasi and loaded into a sandboxed component model environment. They receive proxy events and can mutate requests and responses through a defined interface. The sandbox is restrictive - no filesystem access outside an extension-scoped directory, no network access except through host-provided proxy primitives, no process spawning. This is a deliberate constraint. Burp’s Java extender gives extensions full JVM privilege, which is convenient for the author and a supply chain liability for everyone else. A malicious BApp can read your project files, exfiltrate session cookies, and call out to attacker-controlled infrastructure. The WASM model breaks that. It also means most existing Burp extensions cannot be ported without rewrite. The Logger++, Autorize, and JWT Editor equivalents exist as first-party components. Turbo Intruder does not. For HTTP request smuggling research, that is a material gap. The CL.TE and TE.CL primitives that Turbo Intruder weaponises depend on raw socket control and precise timing that the project’s fuzzer does not currently expose. Smuggling research stays on the Burp side until that primitive lands.

What this enables for vulnerability research. The proxy core and the WASM extender make the project a viable platform for differential analysis research - running the same request through multiple proxies, CDNs, or WAFs and diffing the parsed result. CVE-2021-44228-class injection points where the input crosses a parser boundary become observable in the flow viewer when you can write a 200-line extension to surface them. Header parsing differentials between fronting infrastructure and origin - the class that produced multiple Cloudflare and Akamai bypasses over the last three years - are the project’s strongest research surface. The fuzzer’s concurrency and the proxy’s H2 handling are enough to reproduce most published smuggling primitives short of the Turbo Intruder timing-dependent ones.

What this does not enable. Exploit development for memory-corruption bugs in HTTP stacks is out of scope by design. The project is a proxy, not a fault injector. The fuzzer does not generate inputs designed to corrupt parser state in C-based HTTP servers. AFL++, libFuzzer with HTTP grammar dictionaries, and dedicated protocol fuzzers like boofuzz are the right tools for that work and the project does not try to replace them. Browser-coupled research - DOM XSS that requires JavaScript execution context to trigger, postMessage abuse, prototype pollution chains that reach a sink only after client-side hydration - needs a browser-instrumented tooling layer the project does not have. Burp’s DOM Invader has no equivalent here. Researchers who work that surface keep Burp.

What defenders should see when the project is used against them. The proxy issues requests with a configurable User-Agent. The default is set to a current Chrome string, which is the operator-friendly choice and the defender-unfriendly one. TLS fingerprint differs from a real browser. JA3 and JA4 hashes are distinguishable - rustls produces a cipher suite ordering and extension set that does not match Chromium’s BoringSSL build. A WAF or CDN doing TLS fingerprinting will see the discrepancy. Cloudflare’s Bot Management scores will flag it. Header ordering also differs - the project sends headers alphabetically by default, which no real browser does. For red team work that needs to evade fingerprinting, the project is currently noisier than Burp Pro with stealth extensions. That is a known gap and a tracked issue. From a SOC perspective, the JA3/JA4 signature is a usable detection input. If you see a JA4 hash that does not correspond to a known browser or scanner family hitting your authentication endpoints from a residential IP, that is the project or something built on the same stack.

The license is AGPLv3. The interaction server is separable and runs as its own binary. There is no telemetry. The project will not replace Burp Pro for engagements that depend on Collaborator’s multi-protocol callback handling, Turbo Intruder’s timing primitives, or DOM Invader’s client-side analysis. It will replace Burp Community for the work Community was never sufficient for - sustained research over time, scriptable in a memory-safe extension model, and self-hosted out-of-band infrastructure. The capability gap to Pro is real and named above. The trust gap to Pro - the supply chain risk of running closed-source tooling with full proxy access to your engagement traffic - closes the other direction. Pick the trade that matches the work.