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.tsx and Intercept.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.