Skip to main content
Cordon is a security tool — its entire purpose is keeping secrets out of application processes. This page describes the security guarantees and design decisions.

​
Credential storage

Cordon does not store credentials. Secrets are held by external credential stores and fetched at startup.
SourceConfig valueStorageEncryption
OS keyringkeyringmacOS Keychain / Linux kernel keyringOS-managed (encrypted at rest)
1Password1password1Password vault1Password-managed

​
In-memory secret handling

Secrets in memory are protected with multiple layers:
  • Zeroized on drop — secret values are overwritten with zeros when no longer needed, reducing the window for memory scraping
  • No accidental logging — secrets are masked in all log output and debug representations. There is no code path that can accidentally print a secret value.
  • Explicit access required — the internal architecture requires explicit opt-in to access a secret’s value, making accidental leaks impossible without deliberate code changes
  • No unsafe code — the core library forbids unsafe code at compile time

​
Network security

​
Loopback-only binding

The proxy validates at config load time that the listen address is loopback (127.0.0.1). Non-loopback addresses are rejected. This ensures the proxy is only accessible from the local machine.

​
SSRF protection

Cordon acts as a credential oracle — any process that can reach it can cause authenticated requests to upstream APIs. For untrusted runtimes (AI agents, LLM-generated code), this creates an SSRF risk: a manipulated agent could use the proxy to reach internal infrastructure. Cordon validates all resolved IP addresses against a denylist before connecting upstream. The denylist is always on and not configurable. Blocked ranges include:
  • Private networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  • Loopback: 127.0.0.0/8
  • Link-local / cloud metadata: 169.254.0.0/16 (blocks AWS/GCP/Azure metadata endpoints)
  • CGNAT: 100.64.0.0/10
  • IPv6 equivalents: ::1, fc00::/7, fe80::/10, and more
  • IPv6 transition addresses have their embedded IPv4 extracted and re-checked
Route exemption: Configured routes are exempt from the denylist. A route is an explicit trust decision by the developer. DNS pinning: After DNS resolution, all resolved IPs are validated, then the proxy connects to the validated address directly (not the hostname), closing the TOCTOU window against DNS rebinding.

​
TLS interception

For HTTPS routes, cordon performs TLS MITM using a locally-generated CA certificate. See TLS configuration for details.
  • The CA private key is stored with 0600 permissions
  • The CA cert must be explicitly trusted by the user
  • Per-host certificates use SubjectAltName (not CN) as required by modern clients