Proxy Pass

An internal endpoint trusts an address normally supplied by a reverse proxy. Determine whether a direct client can supply the same trust signal.

Objective

• Send a custom forwarding header and compare authorization results.
• Explain why forwarded metadata is trustworthy only from known proxies.

Before you begin

Open /challenge/medium/proxy, then request the diagnostic endpoint normally.

Concepts

Headers such as X-Forwarded-For are client input unless a trusted proxy removes inbound copies and writes its own value across a controlled boundary.

A forwarding header begins as client input. A trusted proxy removes inbound copies, writes its own assertion, and uses a controlled connection to the origin. The origin verifies that peer before interpreting the assertion; application authorization is still a separate decision.

Suggested tools

• HTTP client: Send one request with an explicit custom header.

Tool practice

Rehearse the worked tool exercise before using challenge data.

Use -H with the complete quoted Name: value argument. Preserve the denied response and compare it with one changed request. The endpoint supplies the header-name clue; the challenge page supplies the address clue. Keep those two sources distinct in your notes.

Investigation

Observe

Record the header-name hint in the denied response and the expected internal address in the challenge page's deployment note.

Form a hypothesis

Does the application verify the request came through a trusted proxy, or only compare the header text?

Test carefully

Change only the evidence-backed forwarding field, send one request, and compare it with the denied baseline.

Progressive hints

Troubleshooting and reset

Header names are case-insensitive, but values must match exactly. This module stores no state and needs no reset.