Lightweight, fast, open-source web proxy for macOS and Windows
A modern alternative to heavy proxy platforms — built in Rust, designed for security testing.

---

What is Sniper?

Sniper is an open-source desktop web security proxy for macOS and Windows. It intercepts, inspects, and modifies HTTP/HTTPS traffic between your browser and the internet — the core workflow for web application security testing, bug bounty hunting, and API debugging.

If you've used an intercepting proxy before, the workflow will be familiar. Sniper is a native desktop app written in Rust with an embedded web UI.

Who it's for: penetration testers, bug bounty hunters, security researchers, and developers who need to see what's happening on the wire.

Install

Windows

Download the latest -setup.exe from Releases and run it. Each installer ships with a .sha256 beside it; check it with Get-FileHash before running, since releases are not yet code-signed.

Run the Windows setup executable built by packaging/windows/make-setup.ps1, or extract a Windows ZIP built by packaging/windows/make-zip.ps1 and open sniper-desktop.exe. Building from source requires the MSVC Rust toolchain. See Windows setup and packaging for WebView2/runtime prerequisites, HTTPS certificates, CLI usage, and isolated testing. Windows x64 is the first port; Linux validation is still pending.

macOS

Download the latest .dmg from Releases, open it, and drag Sniper to your Applications folder.

Or build from source:

cargo run --bin sniper-desktop

Features

Category	What you get
Proxy	HTTP forwarding, HTTPS MITM, authenticated HTTP/SOCKS5 proxy chaining, persistent root CA, https://sniper cert portal
Capture	HTTP history, WebSocket sessions, intercept queue, match & replace rules
Findings	Passive vulnerability scanner — sensitive data, CORS, missing headers, JWT issues
Replay	Modify and resend any captured request
Fuzzer	Payload-based request testing with markers
Tools	Decode, encode, hash, JWT inspector, data transformations
Sessions	Isolated workspaces — each with its own records, scope, and state
Scope	Host and wildcard filtering with site map visualization
Themes	12 themes — 7 dark + 5 light, gold-accent design language
CLI	sniper-cli — JSON-first automation for scripting
AI Skills	Built-in Claude & Codex skill templates using sniper-cli

Why Sniper?

• Native. One Rust binary with no runtime to install. It opens immediately and stays small while it runs.
• Scriptable. sniper-cli speaks JSON for the operations the UI exposes, so reviewing a capture or resending a request can be driven from a shell script.
• Agent-ready. Claude Code and Codex skill templates ship in the repository, so a coding agent drives the same workflow through the same CLI.

Quick start

1. Download and open Sniper
2. Point your browser proxy to 127.0.0.1:8080
3. Visit https://sniper to download and trust the root CA
4. Start capturing

Default listeners:

• Proxy: 127.0.0.1:8080
• UI: 127.0.0.1:23001 (headless mode)

Remote headless UI

The headless UI can bind directly to any local address when remote access is required:

SNIPER_DATA_DIR=/tmp/sniper-headless \
SNIPER_UI_ADDR=192.168.1.10:23001 \
  cargo run --bin sniper

Use 0.0.0.0:23001 instead to listen on every IPv4 interface. Any non-loopback UI listener requires authentication for clients connecting from another host. At startup Sniper prints a URL containing a random one-time token. An exact bind address produces a ready-to-open URL; for a wildcard bind, replace 0.0.0.0 with the machine's reachable address. Sniper exchanges the token for an HttpOnly session cookie, removes the token from the address bar, and rejects any later attempt to reuse it. Restart Sniper to issue a new token if the browser session is lost. Same-machine clients, including sniper-desktop and sniper-cli, remain trusted.

Sniper serves HTTP rather than TLS, so do not expose this listener directly to an untrusted network. Use an SSH tunnel or an authenticated TLS reverse proxy for access across one.

Core workflow

Session → Scope → Capture → Replay → Fuzz
                    │
          ┌─────────┼─────────┐
      Intercept    HTTP    WebSocket
                    │
               Findings (passive scan)

• Session — isolated workspaces with their own records and state
• Scope — define target domains/paths, auto-filter traffic
• Capture — inspect HTTP, intercept & modify, WebSocket frames, auto-replace
• Findings — passive scanner detects sensitive data leaks, CORS misconfig, missing security headers, JWT weaknesses
• Replay — resend with modifications, override host/port
• Fuzzer — insert markers, run payload lists
• Tools — decode/encode/hash/JWT in one place

Proxy chain

In Capture → Settings, enable Proxy chain and enter an upstream proxy address (http://127.0.0.1:8081 or socks5h://127.0.0.1:1080). Optional username and password fields support HTTP Basic authentication and SOCKS5 authentication. socks5:// is also accepted and resolves destination names remotely, like socks5h://. This configures an outbound chain; Sniper's incoming listener continues to accept HTTP proxy requests and CONNECT, not SOCKS client requests.

The chain applies to captured HTTP/HTTPS traffic, TLS passthrough, WebSockets, Replay, and HTTP requests sent by Fuzzer/Sequence. Chain failures never fall back to direct connections. Existing WebSocket connections keep their current route until reconnected. Replay's separate connection-target override cannot be combined with a chain; edit the request destination instead.

Settings belong to each session and persist across restart. Passwords are masked in API responses and stored in the session files on disk. Leaving the masked value unchanged preserves the saved password; clearing it removes the password. Environment proxy variables do not override this explicit setting.

Automation can read settings with sniper-cli capture proxy. To replace them, pipe a JSON object with enabled, url, username, and password into sniper-cli capture proxy --stdin --yes; --dry-run previews the operation without consuming credentials. The manifest operations are capture.proxy.get and capture.proxy.configure (the latter reads settings from stdin).

CLI

sniper-cli ships inside the app bundle. Sniper does not edit your shell profile on its own, so put it on PATH once. Settings ▸ Command line ▸ Add sniper-cli to PATH does it, or:

# Let the app add it to ~/.zshrc (and ~/.bashrc when present) on next launch
SNIPER_INSTALL_CLI_PATH=1 open -a Sniper

# Or add it yourself
export PATH="/Applications/Sniper.app/Contents/MacOS:$PATH"

sniper-cli session list
sniper-cli --output compact capture http list --limit 10
sniper-cli capture http replay --id <id> --dry-run
sniper-cli capture http replay --id <id> --yes
sniper-cli scope set-scope --pattern '*.example.com' --dry-run
sniper-cli scope set-scope --pattern '*.example.com' --yes
sniper-cli fuzzer run --dry-run
sniper-cli fuzzer run --yes

Legacy subcommands keep their original raw JSON success output for compatibility. call success output is wrapped in an automation envelope; use --output compact for one-line JSON and read call results from data.

AI/automation callers can invoke manifest operations directly:

sniper-cli --output compact call capture.http.list --input '{"limit":20,"page":true}'
sniper-cli --output compact call replay.send --input '{"tab_id":"<tab-id>"}' --dry-run
sniper-cli --output compact call replay.send --input '{"tab_id":"<tab-id>"}' --yes

All side-effecting commands with side_effect: "write" in sniper-cli manifest require --dry-run or --yes.

sniper-cli manifest
sniper-cli schema input replay.send
sniper-cli examples capture.http.list
printf "%s" "$OAST_TOKEN" | sniper-cli capture oast configure --provider custom --url https://oast.example --token-stdin --yes

AI integration

sniper-cli skills install --all --dry-run
sniper-cli skills install --all --yes

AI agents can drive the full workflow through CLI — capture, scope, replay, fuzz — no UI scraping needed.

• Using Sniper from Claude Code
• Using Sniper from Codex
• Sniper in an agent harness — which part of a harness this is, and when you do not need it

Documentation

Guide	Answers
Debugging HTTP with Sniper	What can I do with this as a plain intercepting proxy?
Sniper in an agent harness	Which part of my harness is this, and what goes in and out?
Using Sniper from Claude Code	How do I install it, confirm it works, and what can I ask for?
Using Sniper from Codex	The same, for Codex
Architecture	Why it is built this way
Contributing	Build, test, and the invariants to not break

Tech stack

Layer	Technology
Core	Rust — proxy, MITM, TLS, session management
HTTP	hyper + tokio async runtime
TLS	rustls + rcgen for on-the-fly certificate generation
UI server	axum serving embedded SPA
Frontend	Vanilla JS + CSS — zero framework, zero build step
Desktop shell	Native WebView (wry)
Packaging	macOS .app + .dmg; Windows portable .zip with desktop, server and CLI

Build from source

cargo run --bin sniper-desktop   # Desktop app
cargo run --bin sniper           # Headless proxy + UI server
cargo run --bin sniper-cli       # CLI
cargo test                       # Tests
./packaging/macos/release-macos.sh   # macOS .app + .dmg

Project layout

src/
├── proxy.rs           # Proxy core, HTTPS MITM, replay
├── api.rs             # UI/API server (axum)
├── scanner.rs         # Passive vulnerability scanner
├── session.rs         # Session registry & snapshots
├── certificate.rs     # Root CA generation & export
├── store.rs           # HTTP transaction store
├── model.rs           # Normalized data models
├── intercept.rs       # Request intercept queue
├── match_replace.rs   # Auto match & replace rules
├── fuzzer.rs          # Payload fuzzer engine
├── websocket.rs       # WebSocket capture
├── bin/
│   ├── sniper-desktop.rs   # Native desktop shell (wry)
│   └── sniper-cli.rs       # JSON-first CLI
web/                   # Frontend SPA (vanilla JS/CSS)
packaging/
├── macos/             # .app & .dmg packaging scripts
└── skills/            # Claude & Codex skill templates

License

MIT