Skip to content

Tool Integrations

Paul White edited this page Aug 31, 2026 · 1 revision

Tool integrations

Claviger gives each identity a loopback reverse-proxy port. You send requests to the port; Claviger injects that identity's live session and forwards them to the real target, re-authenticating transparently when the token expires. So any tool that can hit a URL can stay logged in for the whole run without knowing anything about the login.

When the daemon starts it prints the ports:

identity admin  -> http://127.0.0.1:8888
identity user-a -> http://127.0.0.1:8889

If you started the daemon with --gateway-token (or --gateway-token auto), every request to a gateway port must carry an X-Claviger-Token: <token> header. The gateway also rejects cross-site requests (a browser Origin or Sec-Fetch-Site), so drive it from your tooling, not from a browser proxied through it.

Burp Suite

Burp is the common case. Point Burp's active tooling at an identity's gateway port instead of the target:

  • Repeater: set the request line to http://127.0.0.1:8889/path, or set the tab target to host 127.0.0.1, port 8889, unchecked TLS. Send as usual; Claviger keeps the identity authenticated between sends.
  • Intruder: aim the attack at 127.0.0.1:8889. A long Intruder run against a session that would normally expire mid-run stays authenticated the whole time, so a wave of 401s does not poison your results.
  • Scanner: define the scan target as the gateway port.

If you use --gateway-token, add the header once under Proxy > Options > Match and replace (or in the Repeater request editor): add request header X-Claviger-Token: <token>.

Two identities, two ports: run one Burp tab per identity to compare how the same request behaves for admin versus user-a by hand, or use claviger replay for the same comparison as a table (see the Authz diffing playbook).

Note Claviger is a reverse proxy, not an upstream forward proxy, so you do not put it in Burp's Upstream Proxy settings. You target its port directly.

curl

curl http://127.0.0.1:8889/api/records/42
curl -X POST http://127.0.0.1:8889/api/records -d '{"x":1}' -H 'Content-Type: application/json'

With a gateway token:

curl -H "X-Claviger-Token: $TOKEN" http://127.0.0.1:8889/api/records/42

ffuf

Content discovery or parameter fuzzing that stays authenticated across an expiry window:

ffuf -w wordlist.txt -u http://127.0.0.1:8889/FUZZ -mc 200,403
ffuf -w ids.txt -u http://127.0.0.1:8889/api/records/FUZZ -H "X-Claviger-Token: $TOKEN"

sqlmap

Point sqlmap at a parameter on the gateway port; the injected session rides along:

sqlmap -u "http://127.0.0.1:8889/search?q=1" --batch --level=2

Add -H "X-Claviger-Token: $TOKEN" when the gateway token is enabled.

nuclei

Run templates through the gateway so authenticated checks see a live session:

nuclei -u http://127.0.0.1:8889/ -H "X-Claviger-Token: $TOKEN"

A tool that only takes a header

For a script or tool that cannot use a proxy port but accepts an Authorization header, print a live one:

claviger header user-a
# Authorization: Bearer eyJ...

This is a point-in-time snapshot, not the auto-refreshed gateway. Fetch it again after the token would have expired, or prefer the gateway port for a long run. claviger header only prints a token for identities that have one; a cookie-only session has no bearer header, so route those through the gateway port instead.

Clone this wiki locally