SaaS custom domain security: verify tenant hosts and TLS safely
Secure customer domains in a multi-tenant SaaS with ownership challenges, exact host-to-tenant mapping, TLS lifecycle controls and takeover tests.
In this guide
How do you secure customer custom domains in a SaaS?
A customer-branded hostname becomes an entry point to your application. Verify control of the exact domain before activation, map that verified hostname to one tenant in trusted server-side data, and remove the mapping when the customer disconnects it. TLS proves control for certificate issuance; it does not by itself authorize a request to access a tenant or keep an old domain assignment safe forever.
Use a deliberate domain verification and lifecycle state
Track each hostname through states such as requested, ownership-pending, verified, certificate-pending, active, suspended and removed. Ask the domain owner to publish a unique DNS TXT challenge or another documented proof, then verify it from your service before activation. Record who initiated the change, the evidence, tenant ID and time; re-check ownership when a domain is reclaimed or moved.
Resolve a verified host to its tenant using server-controlled data
Normalize the incoming hostname, require an exact match in an active domain registry and derive the tenant from that record. Do not accept a tenant ID supplied in a query, arbitrary Host header or client-controlled X-Forwarded-Host. Configure trusted proxies to replace forwarding headers, allow only expected hosts and return a safe error for unknown or suspended domains.
Keep certificate control separate from tenant authorization
Issue a certificate only after domain ownership is established and the hostname is assigned to the intended tenant. The CloudFront example requires a trusted certificate that covers an alternate hostname; provider requirements vary. Do not treat a valid certificate, wildcard or DNS record as permission to read tenant data. Review cookie scope, redirects and absolute links on customer domains as well.
| Hostname and tenant | Ownership proof and date | State and certificate | Trusted routing source | Removal/reclaim test owner |
|---|---|---|---|---|
| portal.customer.example | ||||
| login.customer.example | ||||
| Retired hostname |
How should teams handle domain changes and certificate lifecycle?
Prevent dangling DNS and stale tenant mappings
When a customer removes a CNAME or ends service, disable the hostname mapping and stop serving tenant content before the old destination can be claimed by someone else. Mark the domain unavailable while cleanup is in progress, detach it from the provider, remove certificates or validation records where appropriate, and keep a short audit trail. Re-activation requires fresh verification.
Automate certificate renewal and monitor mismatches
Track certificate subject names, issuer, expiry and association with each active hostname. Test renewal, deployment propagation, failed validation and rollback before expiry. AWS notes CloudFront certificate changes can be asynchronous; use the provider's current operational guidance and alert early rather than waiting for a customer-visible TLS failure.
Keep tenant cookies and links scoped to the right origin
Prefer host-only cookies on a customer hostname; avoid a broad Domain attribute that shares authentication state across unrelated tenants. Generate password-reset, invitation and callback links from a server-maintained, verified origin instead of the request Host header. Review CORS, OAuth redirect registrations, CSP and allowed-origin rules when a domain is added or removed.
What tests catch custom-domain tenant leaks?
Test the full host-to-tenant decision with two customers
Send the same route through tenant A's verified host and tenant B's verified host. Try unknown, mixed-case, trailing-dot, suspended and removed names, as well as a forged Host or X-Forwarded-Host. Confirm the server never falls back to a default tenant and never serves one customer's login, content or metadata on another customer's domain.
Exercise reassignment, DNS loss and concurrent changes
Simulate a DNS record disappearing, a domain being transferred, two tenants claiming the same hostname and a certificate renewal racing with removal. Use an atomic uniqueness constraint for active hostnames and make activation or deletion idempotent. Ensure a background verifier cannot reactivate a domain after an administrator has suspended it.
Review every service that trusts the hostname
Check authentication, password reset, email links, callbacks, static assets, caches, analytics and support tools. A safe page route can still leak through a shared cache key, permissive cookie or absolute URL. Log hostname ID and tenant reference without recording session tokens or sensitive query parameters.
SaaS custom-domain security FAQs
Does a valid TLS certificate prove a customer can access a tenant?
No. It helps prove control of a hostname for HTTPS, but application authorization and an active host-to-tenant mapping still decide which customer data may be served.
Can the application choose a tenant directly from the Host header?
Only after validating the normalized host against a trusted, active domain registry. Do not trust arbitrary Host or forwarding headers, and do not let a missing match select a default tenant.
What should happen when a customer deletes its DNS record?
Suspend serving that hostname, remove the tenant mapping and provider association through a controlled lifecycle, and require fresh ownership verification before another tenant can claim it.
Can one wildcard certificate serve all customer domains?
Provider and certificate rules vary, and a wildcard only covers names within its defined domain boundary. Treat each customer's domain ownership, association and renewal as a separate control decision; test the actual certificate and provider configuration.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Use custom URLs by adding alternate domain names (CNAMEs)Amazon Web Services CloudFront
- Requirements for using SSL/TLS certificates with CloudFrontAmazon Web Services CloudFront
- Testing for Host Header InjectionOWASP Web Security Testing Guide
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- AWS SaaS Lens: Testing multi-tenant SaaS reliabilityAmazon Web Services
- AWS SaaS Lens: Tenant-aware operations and onboardingAmazon Web Services
- OWASP Session Management Cheat SheetOWASP Foundation
- OWASP Cheat Sheet: LoggingOWASP Foundation