Express.js / Advanced: resource, write and release contracts / Lesson 13

Proxy trust, client identity and admission

Interpret forwarded metadata only across a verified proxy topology and keep admission limits tied to trusted identity.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain how trust proxy affects IP, protocol and hostname interpretation.
Separate request admission, authentication and domain resource limits.

Forwarded headers carry claims, not inherent truth

A reverse proxy can terminate TLS and forward requests to Express over a different internal connection. Express may then need a reviewed trust proxy policy to interpret the original client address or protocol. The correct setting depends on the exact reachable topology and how the trusted proxy overwrites forwarded headers. Setting trust proxy broadly without that knowledge can make attacker-supplied metadata influential. Document every permitted ingress path, including shorter paths that bypass an expected hop. A numeric hop count is unsafe when different routes to the app have different lengths unless the topology enforces the assumption.

Record topology assumptions before configuring trust

The JSON is a synthetic review record rather than executable proxy configuration. It asks the deployment owner to identify trusted ingress, header rewriting and bypass prevention. Verify req.ip, req.protocol, req.hostname and secure-cookie behavior through the intended path using an authorized synthetic request before accepting the policy. Do not use a forwarded host blindly to construct password-reset links or public redirects. Even accurately reconstructed client IP is neither a user account nor a stable unique person; shared networks and address changes limit what IP-based decisions can establish.

json Synthetic proxy trust checklist

{"environment":"synthetic-topology-review","ingress":"approved-proxy-only","forwardedHeaders":"overwrite-at-trusted-boundary","directBypass":"must-be-prevented","checks":["client-ip","original-protocol","approved-host","secure-cookie"]}

The record names evidence required before choosing trust proxy. It applies no application or network settings.

Budget input size, concurrent work and principal demand

Rate limits count events over a policy window, while concurrency limits bound active work and payload limits bound individual input. None replaces object authorization or source deadlines. Choose identity dimensions from verified context, and account for shared addresses before blocking every user behind one network. Across multiple app workers, a process-local counter is not a shared global budget. Define the supported store, failure policy, expiry and atomic update behavior for any distributed limiter. Do not advertise a fixed request-per-minute value as universally safe for endpoints with very different cost.

Model a bounded admission decision

This offline function admits work only when both the active-work and per-operation item bounds are satisfied. The synthetic thresholds teach the distinction and are not production recommendations. A real limiter needs atomic acquire/release, cancellation cleanup and a trusted principal key; this Boolean model implements none of them. It is still useful to test that a small payload can be denied when all work slots are occupied, and a free slot does not authorize an oversized request. Keep denial outcomes separate from internal source failures so clients follow the intended retry policy.

javascript Complete offline admission predicate

function admit(active,items) {return active < 3 && items <= 20;}
console.assert(admit(2,20));
console.assert(!admit(3,1));
console.assert(!admit(0,21));

The first synthetic request passes; occupied work capacity and excessive item count each deny independently. No rate store is used.

Verify the boundary without broadening access

Use approved topology records and isolated tests to compare direct and proxy-mediated claims. Fix the trusted-hop policy or proxy rewriting instead of allowing all forwarded values to silence a symptom. Verify secure cookies, redirects, safe host handling and limiter identity together after a change. Observe legitimate rejections and resource cleanup before increasing budgets. This course neither changes a proxy nor runs network traffic or a distributed limiter; it tests only the local predicate and parses the checklist. Real admission enforcement and topology assurance remain deployment-specific responsibilities.

Common errors and fixes

Every caller appears able to choose its client IP

Why it happens: Forwarded claims were trusted across an uncontrolled boundary.
How to fix it: Match trust policy to verified ingress and header rewriting.
Prevent it next time: Test all permitted paths and bypass assumptions.

Each worker allows a full independent global quota

Why it happens: A process-local counter was called a distributed limit.
How to fix it: Use a reviewed shared atomic policy when a global budget is required.
Prevent it next time: Document store failure and multi-worker behavior.

A shared network is blocked as one abusive user

Why it happens: An IP address was treated as unique authenticated identity.
How to fix it: Review trusted principal and network dimensions together.
Prevent it next time: Test legitimate shared-address scenarios.

Check your understanding

1. Why can a hop-count setting fail when an alternate shorter path exists?

Show worked solution

A caller on the shorter route can be closer than the assumed trusted boundary, changing which forwarded values are accepted. The setting is meaningful only with a topology that enforces its assumptions. Review every ingress path and proxy rewriting behavior; do not infer safety from the normal request path alone.

2. Does the admit function implement a safe global limiter?