Trusted Proxy Hops and Forwarded Client Identity

A reverse proxy receives a client request and forwards a new request to an application origin. The origin's socket peer is normally the proxy, not the browser. Headers that describe an earlier client address, host, or scheme are claims; a direct caller can send similar text unless the edge replaces those fields and the origin accepts traffic only from trusted peers. A trust policy therefore starts with the network or authenticated channel between ingress and origin, then defines which hop may set each field. The application must not select the first arbitrary address in a forwarded chain as proof of identity. Address data also does not replace a session or permission check; it is primarily useful for abuse controls, regional rules, and diagnostics.

Working case

A permit portal runs behind two proxies. The public edge terminates TLS and forwards through an internal router to the app. Reviewer 47's request arrives with an address chain containing a client address and two proxy addresses. An attacker sends a direct request to a mistakenly exposed origin with a forged forwarded address that appears to be an office network. A rate limiter and a diagnostic view accept the forged value, while a redirect uses the attacker-supplied scheme. The corrected deployment blocks direct origin access, strips untrusted forwarded fields at the public edge, records the known hop chain, and derives the trusted client address only after verifying the immediate peer.

Implementation boundary

function trustedClientAddress(socketPeer, canonicalAddressFromEdge, trustedPeers) {
  if (!trustedPeers.has(socketPeer)) return null;
  return canonicalAddressFromEdge || null;
}
console.log(trustedClientAddress("direct-visitor", "office-47", new Set(["edge-29"])));
// Output: null

Document each allowed ingress path, including backup edges and health probes. Restrict origin reachability to those peers through network policy or an authenticated connection; a mere header saying edge is not authentication. At the first trusted boundary, remove client-supplied forwarding fields and write a controlled canonical representation. At later hops, append only according to a documented policy. Configure the application to trust the exact peer set and parse the chain from the trusted end, stopping at the first untrusted hop. Reject ambiguous or malformed address data rather than silently treating it as a safe office address. Use a separate verified scheme and host from ingress for secure redirects and cookie decisions. Keep user authorization on server-owned identity, not IP alone. Test direct origin access and a forged multi-hop header.

Cost and boundaries

Forwarding validation adds a small parse per request, but accurate address attribution depends on keeping the trusted peer inventory current. A broad trust range makes attacks easier; a narrow range can break a new proxy rollout until updated. Logging every address hop can increase sensitive-data retention, so record only what incident response requires. Failed parsing should not promote a claimed address into a trusted one. Measure direct-origin attempts, rejected forwarding chains, address-parse failures, and differences between edge and origin scheme or host. If a rate limit groups by client address, verify its behavior under address-sharing networks and privacy relays, where many legitimate users may appear behind one address.

Failure trace

Send a direct request to the origin with a forged forwarded address and verify the network or authentication boundary rejects it. Send through the public edge with an attacker-controlled forwarding header and confirm the edge overwrites it. Add an unexpected third proxy and ensure the app does not trust every chain element by default. Misconfigure the scheme header to HTTP while the browser used HTTPS; redirects and secure cookies should fail a staging check. Rotate a proxy address without updating the allowlist and observe a controlled availability failure rather than silent trust of all origins. Check that a forged address never grants case access.

Verification

Direct origin traffic cannot inject trusted forwarding metadata.
Every hop has an explicit owner for address, scheme, and host fields.
User permission remains session- and object-based.

Practice drill

Map the request path from reviewer 47 through edge 29 and router 62 to an application instance. Record which component sets the canonical address, scheme, and host. Inject a forged first address, a direct-origin request, and one missing hop. Define the expected rate-limit key and redirect scheme for each. Keep a separate reviewer session test so the address value cannot act as authorization. Audit logs for enough information to diagnose a rejected chain without copying full private headers into every trace.

Decision note

Only a known proxy path may supply client metadata; an address claim is never a user permission.

Common Mistakes

Trusting any forwarded header merely because it exists.
Accepting an unrestricted proxy address range.
Using a client IP value as proof of account identity.

Apply and check

Build Project: permit ingress cutover and safe retry and review Web Development: ingress and upstream contracts quiz.