OWASP ZAP is an open-source web-security scanner. Its own proxy records and inspects the traffic between a browser and the sites you are authorised to test; an outbound proxy then forwards ZAP's own connections, so they leave from a proxy IP rather than yours. Set it under Options, in the Network add-on's Connection page: fill the HTTP Proxy section with your order's host, port, username and password, and enable it. Use this only against targets you have written permission to test, the one security use ProxyHive's allowed-use policy permits.

ZAP is free and open source. We ran ZAP 2.17.0 (the official zaproxy/zap-stable Docker image) and configured its upstream proxy against a local HTTP proxy that requires a username and password.

Before you start

  1. Confirm written authorisation for every in-scope host. The policy reserves vulnerability research to systems you own or are contracted to test.
  2. Copy HOST, PORT, USERNAME and PASSWORD from your order at https://app.proxyhive.io.
  3. Check the proxy alone: curl -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org.

HTTP Proxy

On the Connection page the HTTP Proxy section has these fields, in the add-on's documented wording:

FieldValue
Enabledtick to use the proxy
HostHOST from your order
PortPORT from your order
Authenticatetick to send credentials
Realmleave empty
User NameUSERNAME from your order
PasswordPASSWORD from your order
Exclusionsa regular expression of hosts to reach directly

Running ZAP as a daemon, the same settings are config keys, which is how we verified them. Setting network.connection.httpProxy.host, .port, .username, .password, .enabled=true and .authEnabled=true sent a request for a remote site out through the authenticating upstream, and the request arrived at the exit's IP. The password is stored in clear text in ZAP's configuration file unless Store Password is cleared, in which case ZAP prompts at start-up; keep an engagement's config out of shared storage.

Add your in-scope hosts to Exclusions inverted, or narrow the scan's context, so ZAP does not push unrelated traffic through the proxy.

SOCKS Proxy

The SOCKS Proxy section routes at the TCP level:

  • Enabled, Host and Port from your order's SOCKS5 port.
  • Version defaults to 5.
  • Use SOCKS' DNS resolves hostnames at the proxy. The docs describe it as "If the host names should be resolved by the SOCKS proxy. Requires a version 5 SOCKS proxy," and warn that it "might lead to connection failures" for names your hosts file defines locally.
  • User Name and Password for authentication; this password is also stored in clear text.

The interaction matters: the docs say the SOCKS configuration "applies to all ZAP connections, taking precedence over the HTTP proxy," and that loopback addresses are not proxied through it. So enable the HTTP proxy or the SOCKS proxy for your exit, not both expecting independent behaviour.

ZAP's own certificate

ZAP generates a root CA on first run to decrypt the traffic it inspects. Export it from Options > Network > Server Certificates with Save and trust it in the browser or OS doing the testing. This is ZAP reading your in-scope traffic, separate from the outbound proxy that forwards ZAP's connections.

Check the exit IP

Proxy a browser through ZAP and open https://api.ipify.org?format=json, or use ZAP's Manual Request editor. The ip should be the proxy's. If it is yours, the HTTP proxy is not enabled, the host matched an exclusion, or a SOCKS proxy is overriding it. A 407 means the credentials did not reach the proxy; the proxy error codes guide decodes the rest.

With ProxyHive

An authorised scan that must originate from one declared address suits a datacenter IP: a static exit in the country you pick at checkout that the target's owner can allowlist, with HTTP, HTTPS and SOCKS5 and username and password authentication. For the commercial tool with the same upstream-proxy model, see Burp Suite.