Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Host Authority Routing and Default Deny

Last updated: 5 Oct 20268 min read
tutorial
IntermediateBy AITrove Editorial

An ingress routes a request partly by its target authority: the hostname and optional port that identify the requested service. TLS may select a certificate using a name offered during the handshake, while HTTP carries the target host or authority in the request. These names can disagree, and a proxy chain can rewrite them. A default virtual host that sends every unknown name to the application can expose pages through unintended domains, poison generated links, or bypass cookie assumptions. Routing should allow the names the product owns, preserve the intended tenant or service mapping, and reject unrecognized authorities before application code builds absolute redirects or account links.

Working case

The permit portal serves a public guide and a private reviewer app from the same ingress. An old test hostname still resolves to the ingress, and a request with that host lands on the private app because the default route points there. A password reset handler builds an absolute link from the request host. The recipient receives a link under an attacker-controlled name even though the account record is valid. The corrected ingress has an explicit host allowlist and a safe default rejection. Application-generated account links use a configured canonical origin, while the router passes a server-approved host identity to the app for tenant-aware pages.

Implementation boundary

javascript
function routeForAuthority(requestHost, allowedHosts) {
  const normalizedHost = requestHost.toLowerCase();
  return allowedHosts.get(normalizedHost) || "reject";
}
console.log(routeForAuthority("old-test.permit.invalid", new Map([["portal.permit.invalid", "review-app"]])));
// Output: reject

Inventory production, staging, legacy, and customer-owned hostnames. For each, define the certificate coverage, ingress route, backend target, cookie domain, canonical redirect, and whether absolute links may be generated. Reject unknown hosts at the first routing layer instead of letting a privileged service become the default. If HTTP host and TLS name differ, decide whether that pair is permitted before forwarding. Normalize host case and a permitted port representation while rejecting malformed or duplicate authority signals. A proxy should not pass an arbitrary browser Host through to origin code as a trusted canonical base URL. For tenant custom domains, resolve a verified domain-to-tenant mapping on the server and plan revocation. Test all expected names and an unknown name through every region.

Cost and boundaries

A host allowlist adds operational work for new domains and migrations. The cost is small at request time for a bounded lookup, but mistakes can cause outages during cutover if DNS, certificates, and route tables change at different times. A permissive default seems easier during setup and can silently serve sensitive pages on old or attacker-controlled names. Tenant-domain mappings add storage and verification state; they must be removed when ownership changes. Measure requests rejected by authority, mismatched TLS and HTTP names, redirects to unexpected hosts, and login-cookie failures after domain changes. Review account links in a mail sandbox before production release.

Failure trace

Send an unknown Host with a valid TLS connection and confirm the ingress rejects it rather than serving the reviewer app. Request a known HTTP authority under a different TLS name and verify the configured policy. Supply duplicate authority fields through a test proxy and ensure they are not merged into an ambiguous route. Remove a verified custom domain from a tenant, then attempt to reach a stale backend mapping. Generate a password reset message while the incoming request uses an unexpected host; the link must use the configured canonical origin, not the untrusted request text.

Verification

  • Every production hostname has a declared certificate and route.
  • Unknown or revoked hosts cannot reach a privileged default app.
  • Account links use configured canonical origins.

Practice drill

Create an allowlist for the public guide, reviewer app, API, and one verified customer domain. For each name, record certificate, route target, canonical origin, and cookie scope. Route cases 29 and 47 under the expected authorities, then probe an old staging name and an unknown name. Revoke the customer domain while DNS still points to the ingress and prove it no longer selects that tenant. Inspect one account link generated during an unknown-host request and verify its base comes from configuration.

Decision note

Unknown authorities fail at ingress; user-facing absolute links come from configured origins.

Common Mistakes

  • Pointing a catch-all virtual host at a private application.
  • Building account links from a raw request Host.
  • Assuming TLS name and HTTP authority always match.

Related lessons

Ingress Proxy and Upstream Contracts; Trusted Proxy Hops and Forwarded Client Identity; Ingress Health, Readiness, and Connection Drain; Proxy Body Budgets, Timeouts, and Retry Ownership; DNS TTL, Negative Cache, and Cutover Planning; TLS Certificate Rotation and HSTS Scope.

Apply and check

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

web-tech
web-development
Storage details