HTTP Proxy

The HTTP proxy uses native clients such as a browser, CLI, or application configured to send requests through Bridge. It has no browser session page. Configure the common bsh settings first.

Configure a capture scope

Set these permission variables to allow the named hosts, block selected methods, and extend recording redaction:

BSH_CAPTURE_HOSTS=api.internal.example.com
BSH_CAPTURE_SUBDOMAINS=svc.internal.example.com
BSH_BLOCKED_METHODS=DELETE,PUT
BSH_SANITIZE_HEADERS_EXTEND=x-internal-token
BSH_SANITIZE_BODY_FIELDS_EXTEND=ssn,card_number

bsh’s capture-scope method changes no target accounts or credentials. It registers the allowed destinations with Bridge:

#!/bin/sh
exec bsh checkout http --method capture-scope --mode bridge

#!/bin/sh
exec bsh checkin http --method capture-scope --mode bridge

Checkin removes the Bridge checkout. Active proxy connections close, and the client cannot start new requests under that grant.

Verify

Request the permission through Britive. Configure your client to use the proxy address and Bridge credentials returned by the checkout. The default HTTP proxy port is 8443. HTTPS interception also requires the client to trust Bridge’s MITM CA.

Confirm that an allowed destination works and that an out-of-scope destination is refused. See the HTTP proxy reference for TLS setup and recording behavior.

Keep a target bearer token in Bridge

In v3.0.2 and later, the checkout API accepts a bearer token in target_password, with an exact target_host and an explicit target_port. Bridge requires HTTPS and verified target certificates.

bsh currently reads BSH_TARGET_BEARER_TOKEN but omits the required host and port from its HTTP checkout payload. Use the API-based kubectl example for bearer injection.