Learning outcomes
- Distinguish reverse, forward, transparent, and identity-aware proxy paths.
- Identify who selects the proxy, who selects the destination, and which identity it can verify.
- Place policy without confusing traffic mediation with application authorization.
- Detect direct paths, ambiguous trust, and unsupported protocol assumptions.
Protection need
Choose a proxy from the path and protected resource. A reverse proxy stands in front of selected origins and receives requests addressed to those published services. A forward proxy acts for clients that use it to reach many destinations. A transparent proxy intercepts traffic without an explicit application proxy configuration. An identity-aware proxy is an enforcement role that authenticates a principal and evaluates policy for named resources.
These descriptions can overlap. A reverse proxy can be identity-aware. A forward proxy can enforce identity policy. The traffic direction does not prove the security function.
Security objectives and requirements
For each proxy, define the client, destination, name and route source, protocol, TLS endpoint, authenticated principal, policy resource, upstream identity, bypass boundary, and evidence. State whether clients intentionally address the proxy or infrastructure redirects them.
Keep application permission with the application. A proxy route allow does not authorize every record or action behind the route.
Security invariants and evidence
- The selected destination and attached policy refer to the same route.
- The proxy authenticates the identity that policy uses.
- The origin accepts traffic only from intended paths.
- Identity fields cannot be supplied or preserved by an untrusted client.
- Evidence records route selection, principal, policy result, and upstream.
Failure cases
- A reverse proxy publishes an origin that remains directly reachable.
- A forward proxy sends credentials to an attacker-selected destination.
- Transparent interception breaks authenticated end-to-end assumptions.
- A proxy trusts source address as user identity.
- An identity-aware route is mistaken for application object permission.
- A protocol upgrade or alternate port avoids the intended control.
Design tradeoffs and residual risk
Explicit proxies make routing and trust visible but require client or application configuration. Transparent interception can cover legacy traffic but adds protocol and identity ambiguity. Reverse proxies simplify origin protection but only cover published services. Forward proxies can govern broad egress but need strict destination and credential rules.
Prefer the narrowest path that can name and mediate the protected resource.
Pomerium boundary
Pomerium primarily provides identity-aware reverse-proxy routes and documented non-HTTP access paths. It is not a general transparent network perimeter. Pomerium route policy does not replace upstream object and action authorization.
Exercise
Draw four paths: private web application, employee web egress, legacy TCP database, and service-to-service API. For each, name the client, proxy type, destination selection, TLS endpoints, principal, resource, policy, and bypass risk.
Reject any design that relies only on the word "proxy" to describe its trust or security role.
Evaluation checklist
- Who intentionally addresses or configures the proxy?
- Who selects and authenticates the target destination?
- Which principal and protected resource can the proxy name?
- Can traffic or credentials reach the target outside the intended path?
- Which application permission remains after the proxy allows the route?
Next learning unit
Context-Aware Proxy
A context-aware proxy is a policy enforcement point placed between a requester and a protected service.
