Skip to main content

In scope

ThreatMitigation
Credential leakage via logsAll secret values are masked in log output
Credential leakage via memorySecret values are zeroized when no longer needed
Credential theft from diskOS keyring (encrypted at rest), no plaintext credential files
SSRF through the proxyIP denylist on all upstream DNS resolutions
DNS rebinding attacksDNS pinning — connect to validated IP, not hostname
Unauthorized network access to proxyLoopback-only binding (127.0.0.1)
Accidental credential exposure in codeExplicit access gating, no unsafe code allowed
Cloud metadata access via proxyLink-local range (169.254.0.0/16) blocked by default

Out of scope

ThreatRationale
Malicious process on the same machineSame-user processes can read loopback traffic and (on Linux) keyring entries. Local machine compromise is outside the trust boundary.
Root/admin accessRoot can read keychain, memory, and loopback traffic.
Supply chain attacks on dependenciesManaged by dependency auditing and SAST in CI, not by cordon’s runtime security model.
Compromised upstream APICordon injects credentials into requests to the configured upstream. If the upstream is compromised, the credentials are exposed to the attacker. This is inherent to any credential injection system.

SSRF attacker model

The primary SSRF threat comes from AI agents or LLM-generated code that controls the destination of HTTP requests routed through the proxy. Attacker capabilities:
  • Controls the destination host, port, path, headers, and body
  • Can make arbitrary HTTP requests through the proxy
High-value targets:
TargetRisk
Cloud metadata (169.254.169.254)IAM credential theft
Localhost servicesData exfiltration, RCE
Private networks (RFC 1918)Lateral movement
Defenses:
  • All resolved IPs checked against the denylist before connection
  • IPv6 transition addresses have embedded IPv4 extracted and re-checked
  • DNS pinning prevents TOCTOU attacks via DNS rebinding
  • Configured routes are exempt (explicit trust decision by the developer)