The Problem
Security researchers need an open-source alternative to Burp Suite Pro for intercepting, logging, and replaying HTTP traffic. Hetty addresses that with a self-hosted MITM proxy and web-based admin interface, storing all data locally in a BoltDB file.
What This Does
Hetty runs a single binary that serves three things: an HTTP MITM proxy (pkg/proxy/proxy.go), a GraphQL API (pkg/api/resolvers.go), and a Next.js admin UI (admin/src/pages/). The proxy logs requests and responses, supports scope-based filtering (pkg/scope/scope.go), and allows intercepting/modifying traffic in flight (pkg/proxy/intercept/intercept.go).
The admin interface is organized by feature—sender/ for replaying requests, reqlog/ for searchable logs, intercept/ for live modification, projects/ for workspace management. All data persists to a single BoltDB file via pkg/db/bolt/.
How It Is Wired
Execution starts at main in cmd/hetty/main.go:15, which reaches 6 functions. The traced path is Exec -> OpenDatabase — two hops from entry to the filesystem via bolt.Open in pkg/db/bolt/bolt.go. No database or network edge exists beyond that.
The GraphQL layer is the hub. pkg/api/generated.go defines 296 functions and 8 types, and is called from only 1 other file — it's a generated monolith (8,109 lines) that everything else routes through. pkg/api/resolvers.go (44 functions) is called from 6 files and handles the actual query/mutation logic.
The most-connected functions carry the widest blast radius: UpsertProject (called from 13 places), Close (13), DatabaseFromBoltDB (9), ActiveProject (8). marshalNBoolean2bool is called from 16 places — change its signature and you break a quarter of the GraphQL layer.
The module graph shows no circular dependencies across 106 files and 23 import edges. That's clean. The cost is concentration: generated.go and resolvers.go are where most changes land, and both are already flagged as oversized.
How To Use It
Setup: Build from source with Go modules (go.mod present) or use the Dockerfile. The README documents docker run -v $HOME/.hetty:/root/.hetty -p 8080:8080 ghcr.io/dstotijn/hetty:latest.
Configuration: No env vars required. Flags are defined in cmd/hetty/config.go: --cert, --key, --db (defaults to ~/.hetty/), --addr.
Running it:
hetty --addr :8080
Then open http://localhost:8080 for the admin UI. The proxy listens on the same port.
Real-World Use
For a bug bounty engagement: start Hetty, configure your browser to use it as an HTTP proxy, navigate the target site. Requests appear in the reqlog view with searchable filters (pkg/reqlog/search.go). When you find an interesting request, send it to sender/ to replay with modifications, or enable intercept mode to edit requests before they reach the server.
Code Health & Issues
Static analysis found 27 findings (2 high, 20 medium, 5 low) across 9 kinds:
- High — Duplicated code blocks: 109 repeated 6-line blocks across 22 files, notably in
EditRequest.tsxandIntercept.tsx. Fix: extract shared helpers. - High — Oversized files:
pkg/api/generated.go(8,109 lines),admin/src/lib/graphql/generated.tsx,pkg/api/resolvers.go. Fix: split by responsibility. - Medium — Deep nesting (13 instances), high branching density (4 files), empty catch block in
AddRule.tsx. - Low — 33 TODO/FIXME markers across
generated.go,filter.go,search.go,EditRequest.tsx.
SDLC findings from the CI/Docker setup: workflows lack least-privilege permissions declarations, no Dependabot config, yarn install without --immutable in CI, unpinned base images in Dockerfile, no dependency vulnerability scan, persist-credentials not disabled, and no non-root USER in the image. Tests exist (12 files) and CI runs via GitHub Actions.
The Bottom Line
A functional Burp Suite alternative with a clean Go/React split and no structural red flags. The GraphQL layer is the bottleneck — generated code dominates and will make changes expensive. Suitable for security researchers who want a self-hosted, auditable proxy tool, not for teams needing the full Burp feature set.