Blog post
What Front Door gives us—and what it does not hide
The edge gives every tenant a custom hostname, global cache, managed certificate, and redirects before origin. It does not turn a public static website endpoint into a private origin, and our design should never imply otherwise.
- Prove the name Creating a custom domain mints a
_dnsauthtoken. The public TXT answer must match before Azure approves it. - Serve managed TLS Front Door maintains the certificate. A leaf-wide visitor policy applies to production and its environments.
- Encrypt the origin hop Front Door connects over TLS to the storage website hostname. Its own default hostname returns 404.
- State the bypass Anyone who learns the website endpoint and project prefix can request origin directly. The prefix is obscurity, not a firewall.
Approval is a public DNS fact
A green DNS panel is not the same as a Front Door domain reporting Approved. Azure polls for its exact validation token, and route attachment waits behind that proof when another team controls the zone. Tenant workload identity has no DNS permission. The full handoff is in our DNS and TLS post.
Two encrypted connections
The visitor negotiates TLS with the managed certificate on the custom domain. Front Door then makes a separate TLS connection to the *.web.core.windows.net origin. The custom-domain policy controls the first connection, not the second.
We disable useful serving through the profile's default Front Door hostname—it returns 404—so tenant content is reached through its named custom domains. Shared-key authorization on the storage account is disabled, and anonymous Blob REST access to $web is not enabled.
The origin is still public
Azure Static Website requires its website endpoint to be publicly reachable. If someone knows both that endpoint and a tenant's UUID prefix, they can bypass Front Door and fetch the website path directly. This tier has no Web Application Firewall or Private Link. A hard-to-guess prefix reduces accidental discovery; it is not a security boundary.
Redirects in front of origin
Front Door rule sets can return a temporary 307 before cache lookup or origin forwarding. Specific paths may redirect while everything else continues to the site's static files; a catch-all can make a hostname redirect-only without removing its domain, route, or repository.
In the proposed catalog, Basic permits only one fixed redirect shape: one live FQDN, one unconditional whole-host 307 to a validated HTTPS destination, and no preview or origin content. Path-specific rules, content mixed with redirects, or multiple source FQDNs require an Intermediate reservation or the maximum Dedicated reservation. Platform identity—not the tenant uploader—validates and applies every edge rule.
For an apex family, www.xyz.tld redirects to xyz.tld and www-preview.xyz.tld redirects to preview.xyz.tld, preserving path and query. These are client redirects, not reverse-proxy rewrites.
After attaching a rule, the platform purges the source hostname for the exact tree now covered. A host-wide redirect requires /*, because even a cached fingerprinted asset must stop returning 200 and start returning 307. The same hostname allowlist used by deploy protects that broader operation.
Next: how stored objects eventually age out, or return to all posts.