Eight months building a Burp Suite replacement

Burp Suite Professional costs $475 per user per year. The community edition is throttled, can’t save projects, and has no scanner. I spent eight months building an open-source replacement called Interceptor, and what I learned about the proxy market - and about handing a tool like this to anyone with a download button - is worth writing down before the GitHub stars become the story.

What the tool actually does

Interceptor is an intercepting HTTP/HTTPS proxy written in Rust with a Tauri front-end. It sits between a browser and a target server, decrypts TLS using a locally generated CA certificate the user installs, and lets you read, modify, and replay every request. It has a repeater, an intruder-style fuzzer with four payload modes, a passive scanner that flags missing security headers and obvious injection sinks, and a WebSocket inspector. It does not have an active vulnerability scanner. That gap is deliberate, and I’ll explain why below.

The core proxy handles roughly 1,200 requests per second on a 2021 M1 with TLS termination on. Burp on the same machine handles about 900. The speed isn’t a virtue - it’s a side effect of Rust and the fact that Interceptor doesn’t run the dozens of background checks Burp does. Different tradeoffs, same plumbing.

Why open-sourcing a proxy is not the same as open-sourcing a linter

A local proxy that decrypts TLS is dual-use software. The same code that lets a bug bounty hunter find an IDOR in a SaaS billing endpoint also lets a stalker read their partner’s session cookies off the home Wi-Fi. I went back and forth for two months on whether to release it at all. The argument that tipped me: Burp Community, mitmproxy, Caido, ZAP, and Fiddler already exist. Every technique Interceptor enables is enabled by tools released between 2003 and 2022. I’m not lowering a barrier, I’m widening a doorway.

That reasoning has a limit, though. There are two features I cut before release. The first was a one-click “install CA on this device over the LAN” helper aimed at testing mobile apps - it worked, and it was also a near-perfect adversary-in-the-middle kit for a roommate or a small office. The second was an automated credential-replay module that would re-submit captured login forms against a list of subdomains. Useful for testing SSO misconfigurations, also useful for credential stuffing against the user’s employer. Both stayed on the cutting room floor. Anyone determined enough to write them in Python in an afternoon can, but I’m not shipping them with a polished UI.

The license question is harder than it looks

I shipped under AGPL-3.0. MIT was the default I almost picked, and I want to walk through why I changed my mind, because most security tool authors don’t think about this until someone forks their work into a commercial product.

MIT lets anyone - including a vendor selling offensive tooling to governments with poor human rights records - take the code, rebrand it, add a C2 backend, and ship it. AGPL doesn’t prevent that, but it forces them to publish their modifications if they offer it as a network service. That’s a small obstacle for a sophisticated buyer and a real obstacle for a sloppy reseller. It also makes the code unusable in most commercial pen-test platforms without a separate license, which I’m fine with. If a consulting firm wants Interceptor in their managed offering, they can email me and we can talk.

The practical effect: in the first six weeks after release, three companies asked about commercial licensing. Two were security firms doing internal training. One was a vendor whose product page mentioned “lawful intercept” and “deniable operations.” I told the third one no. AGPL gave me a reason to have that conversation at all. MIT would have skipped it.

What an open-source proxy changes for defenders

The interesting security implication isn’t on the attacker side, where the marginal new capability is near zero. It’s on the defender side, where the economics shift.

A security team that wanted to teach twenty engineers how to read raw HTTP traffic used to either buy twenty Burp Pro licenses ($9,500/year), use the crippled community edition, or build internal training around mitmproxy’s command-line interface. The first is expensive, the second is frustrating enough that engineers give up, the third has a learning curve that loses people in the first hour. A free GUI tool with a repeater and a usable interface drops the cost of basic web security literacy inside a company to roughly zero. I’ve already had two internal security leads tell me they’re rolling it out for application security training in 2026.

The second-order effect: developers who can read their own app’s traffic catch more bugs before they ship. Not because the tool is magic, but because friction is what kept them from looking in the first place. Every security person reading this knows the developer who has never seen their own JWT decoded. Cutting that friction is worth more than another scanner rule.

What it changes for attackers

Less than people will assume. Real attackers - meaning people who do this for money or for governments - already have Burp Pro, internal tooling, or both. The capability ceiling for serious offensive work is set by skill, not tool budget. Interceptor doesn’t move that ceiling.

Where it does move things is the floor. A teenager curious about how login forms work now has a polished, free tool with documentation in the same way a teenager in 2008 had Cain & Abel. That’s been true since ZAP shipped in 2010. The cybercrime numbers since then are driven by phishing kits, infostealer malware, and ransomware-as-a-service - not by people getting better at manual HTTP manipulation. The link between accessible proxy tools and actual harm is weaker than the discourse suggests.

The place I am genuinely worried is harassment and intimate partner abuse. A free, polished, easy-to-install proxy lowers the bar for someone with physical access to a victim’s devices to read their traffic. I added two mitigations: the CA certificate has a clearly visible warning banner when traffic is being intercepted, injected as a meta tag into HTML responses by default; and the installer refuses to silently install the root CA without an OS-level admin prompt. Neither stops a determined abuser. Both make casual surveillance harder and create forensic artifacts a victim’s advocate can find later.

Where the code lives and what’s actually in it

The repository is on GitHub under random-chaos/interceptor. Roughly 38,000 lines of Rust, 12,000 lines of TypeScript for the UI, and a test suite that covers the proxy core at about 81% line coverage. The fuzzer is the weakest part - payload generation works but the result analysis is naive, and I’d recommend FFuf or Burp’s Intruder for anything serious until the next release.

Three things to know if you’re going to run it:

The CA private key lives at ~/.interceptor/ca.key with 0600 permissions. If you share a machine, that file is the entire trust boundary. Delete it when you’re done testing.

The project storage format is SQLite, unencrypted by default. There’s an opt-in flag for SQLCipher with a passphrase. Captured traffic includes session cookies, auth tokens, and sometimes plaintext credentials, so treat the project file as you’d treat a database dump.

Update channel is GitHub releases only, signed with a Sigstore certificate tied to my GitHub identity. There is no auto-update. I won’t add one. An auto-updating local proxy with TLS interception privileges is a supply chain attack waiting to happen, and I’d rather lose users to update fatigue than ship that.

What I would change if I started over

I’d write the UI in something other than Tauri. The cross-platform story is good, but the WebView dependency means the front-end’s security model is at the mercy of the host OS’s browser engine, and I’ve already had to ship one patch for a Windows WebView2 issue that allowed a malicious response body to break out of the renderer sandbox. A native UI in egui or Qt would have avoided that whole class of bug.

I’d also start the threat model document on day one instead of day 180. Half the design decisions above were made retroactively, after users asked questions I should have answered before I wrote the first line. If you’re building a security tool: write the threat model before the proxy. Your future contributors and your future self will thank you.

The repo is open. Issues are open. If you find something that should be cut, file it.