Back to Articles

Hetty: Building an Open-Source Burp Alternative with Go and GraphQL

[ View on GitHub ]

Hetty: Building an Open-Source Burp Alternative with Go and GraphQL

Hook

While Burp Suite Pro costs $449/year and owns the enterprise security market, a 9,300+ star open-source alternative written in Go is quietly gaining traction among bug bounty hunters who want modern tooling without the price tag.

Context

For over a decade, web security researchers have faced an uncomfortable choice: use free but clunky tools like OWASP ZAP and mitmproxy, or pay hundreds of dollars annually for Burp Suite Pro. The former meant wrestling with Java-based UIs from the 2000s or learning complex CLI workflows. The latter meant justifying enterprise software costs for individual researchers and hobbyists.

Hetty emerged to challenge this dichotomy. Created by dstotijn and released under the MIT license, it’s designed specifically for the modern infosec and bug bounty community. Rather than trying to clone every Burp feature, Hetty focuses on the core MITM proxy workflow that security researchers use daily: intercepting HTTP traffic, searching through request/response logs, manually crafting requests, and managing test scopes. By building with Go’s performance characteristics and a GraphQL API architecture, Hetty delivers a web-based admin interface that feels native to 2024, not 2004.

Technical Insight

HTTPS Requests

Intercepted Traffic

Signs Certificates

Store Requests/Responses

Query Projects

Filtering & Search

View Logs & Craft Requests

Execute

Client Browser

MITM Proxy

TLS Interception

CA Certificate

~/.hetty/

SQLite DB

Projects

GraphQL API

Backend

Web Admin

Interface

System architecture — auto-generated

Hetty’s architecture centers around three loosely coupled components that communicate through well-defined interfaces. At the core sits an HTTP/HTTPS MITM proxy that intercepts traffic using custom CA certificates. Unlike traditional proxies that process requests in memory, Hetty persists everything to SQLite in a project-based database structure, allowing you to close the application and return to your testing session exactly where you left off.

The proxy layer handles TLS interception by generating certificates on-the-fly. When you first run Hetty, it creates a root CA certificate and private key in ~/.hetty/ (configurable via --cert and --key flags). As intercepted HTTPS requests arrive, the proxy signs leaf certificates for each domain using this root CA. This is the same technique Burp and mitmproxy use, but Hetty simplifies the workflow with a --chrome flag that launches Chrome with the certificate automatically trusted:

hetty --chrome --addr :8080

This single command starts the proxy on port 8080, launches Chrome with proxy settings pre-configured, and bypasses certificate warnings. No manual certificate installation, no proxy configuration dialogs. For penetration testers who spend their days switching between targets, this workflow optimization saves genuine friction.

The second layer is a GraphQL API that sits between the proxy and the frontend. This is where Hetty’s architecture diverges most significantly from tools like Burp. Rather than building a monolithic application with tightly coupled UI and backend logic, Hetty exposes proxy functionality through GraphQL queries and mutations. Want to search through captured requests? Query the API with filters. Need to replay a request with modifications? Send a mutation with the edited payload.

This GraphQL-first design has cascading benefits. The web interface becomes a thin client that’s essentially a GraphQL consumer, making it possible to build alternative frontends or programmatic integrations without reverse-engineering a proprietary API. You could theoretically build a CLI client, a VS Code extension, or automation scripts that query the same GraphQL endpoint the web UI uses. While Hetty doesn’t ship with these integrations today, the architectural foundation makes them feasible.

The SQLite storage layer deserves particular attention. Hetty uses a project-based model where each testing engagement gets its own .db file. Starting a new project is as simple as:

hetty --db ~/pentest/client-acme/acme.db

Inside this database, Hetty stores raw HTTP requests and responses with full headers and bodies, along with metadata like timestamps, scope status, and user annotations. The schema supports full-text search capabilities, enabling the admin interface to offer filtering like “find all requests to api.example.com containing ‘user_id’ in the response body.” For anyone who’s struggled to grep through text-based proxy logs or waited for Burp’s Java-based search to churn through gigabytes of data, SQLite’s indexed search appears to offer responsive performance.

The web-based admin interface completes the stack. Built as a modern single-page application, it provides views for proxy logs, manual request crafting (similar to Burp’s Repeater), and intercept functionality where you can pause requests mid-flight to modify them before forwarding. The scope management feature lets you define which domains are in-scope for your test, automatically tagging requests and preventing your database from filling with noise from third-party trackers and CDNs.

Gotcha

Hetty’s biggest limitation is explicitly stated in the README: it’s under active development and incomplete compared to commercial alternatives. Critical features that professional penetration testers rely on daily—automated vulnerability scanning, intruder-style fuzzing, and Collaborator-equivalent out-of-band interaction testing—simply don’t exist yet. The project’s GitHub backlog shows these as planned features, but if your workflow depends on automated scanning to identify low-hanging fruit before manual testing, Hetty won’t replace your existing toolchain.

The single-user, desktop-application architecture also creates friction for team-based pentesting. There’s no built-in mechanism to share a project database across multiple researchers, export findings in a standardized format for reporting, or collaborate in real-time on the same test engagement. While you could theoretically share the SQLite database file through Dropbox or version control, SQLite’s single-writer constraint means simultaneous access will cause corruption. Professional security teams accustomed to Burp Suite Enterprise’s collaboration features will find Hetty’s project model isolating. Additionally, while SQLite performs well for typical security testing workloads, proxy sessions that generate hundreds of thousands of requests (think: automated crawlers or long-running authenticated sessions) may experience performance degradation as the database file grows to gigabytes.

Verdict

Use Hetty if you’re doing manual security testing or bug bounty hunting as an individual researcher, want a modern web-based interface without the complexity of Burp Suite’s Java UI, and don’t need automated scanning features. It’s particularly compelling for developers who are security-curious and want to understand how their applications behave at the HTTP level without investing in commercial tooling. The MIT license and project-based workflow make it ideal for learning, hobbyist research, or scenarios where you need to spin up a proxy quickly without licensing concerns. Skip Hetty if your professional workflow requires automated vulnerability scanning, team collaboration features, or proven stability for client engagements where tool reliability directly impacts deliverables. In those scenarios, the $449/year for Burp Suite Pro is professional insurance worth paying, or consider mature open-source alternatives like OWASP ZAP that have a decade of hardening. Also skip it if you’re comfortable with CLI tools and need advanced scripting capabilities—mitmproxy’s Python-based architecture offers more programmatic control than Hetty’s current feature set.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/dstotijn-hetty.svg)](https://starlog.is/api/badge-click/cybersecurity/dstotijn-hetty)