Routing decision
Route selection maps an accepted request authority, scheme, port, and path to a protected policy and upstream. The selected route decides where credentials and identity context travel. Treat it as a security decision, not only a traffic-management function.
Validate the authority
Accept only configured hostnames and schemes. Keep the transport-layer server name, HTTP authority or Host field, external URL, policy route, and upstream mapping consistent. Normalize paths once, reject ambiguous encodings, and define how forwarded host fields are created. Do not trust an unverified client header to select a privileged backend.
Bind policy and destination
Attach policy to the same canonical route object that selects the upstream. Ensure redirects remain on approved origins. Restrict wildcard and catch-all routes. Keep administrative and tenant routes separate when their policy or identity destination differs.
Failure and residual risk
Host-header attacks, domain fronting, conflicting proxy fields, ambiguous paths, wildcard precedence, and open redirects can select the wrong route. A correct route can still target an exposed or misconfigured upstream. DNS resolution alone does not authenticate the destination.
Pomerium boundary
Pomerium selects configured routes and upstreams from incoming request data. Operators must configure exact route identities, trusted proxy boundaries, and upstream transport. Applications must validate their own external origin assumptions and resource authorization.
Evaluation checklist
- Are accepted scheme, authority, port, and path forms explicit?
- Do transport and HTTP authority select the same intended route?
- Can wildcard, catch-all, or forwarded fields reach a more privileged upstream?
- Are policy, redirect, credential forwarding, and upstream bound to one route?
- Do tests cover unknown hosts, duplicate fields, encoded paths, and wrong ports?
