WAF for SaaS custom domains

Letting customers bring their own domain — app.acme.com instead of acme.yoursaas.com — is one of the highest-leverage features a SaaS platform can ship. It makes the product feel native to each customer's brand, improves deliverability and trust, and is frequently a requirement to close enterprise deals. It is also, quietly, one of the largest expansions of your attack surface you will ever make. Every custom hostname you serve is a new public entry point into your multi-tenant infrastructure, and every one of them needs a valid certificate, a clear owner, and a policy.

This article walks through how to protect SaaS custom domains at scale: isolating tenants, applying per-tenant policy, and running a certificate workflow for customer hostnames without the web application firewall ever holding a private key. The pattern below is how ArxLayer protects SaaS platforms in production.

Custom domains: a growth lever and an attack surface

From a product perspective, a custom domain is a single CNAME the customer points at your platform. From a security perspective, it is far more. You are now terminating TLS, parsing requests, and routing traffic for a hostname you do not own, on behalf of a tenant whose security posture you cannot control. Attackers treat this surface as an opportunity: probing for tenant confusion, subdomain takeover of dangling DNS records, certificate misissuance, and request smuggling between the hostname they control and the platform behind it.

The throughput problem compounds the security problem. A successful SaaS platform does not onboard one custom domain; it onboards thousands, continuously, with no human in the loop. The protection model has to be automatic, auditable, and uniform across every tenant — not a bespoke configuration that someone hand-edits per customer. That is fundamentally an architecture question, which is why custom-domain protection lives or dies on how your multi-tenant WAF architecture is designed.

Multi-tenant isolation comes first

Before you serve a single customer hostname, the platform has to guarantee that one tenant cannot see, influence, or inherit another tenant's configuration. In ArxLayer, the domain is a first-class, tenant-scoped resource. A custom hostname is bound to exactly one tenant, its policy is resolved only within that tenant's namespace, and there is no shared mutable state that a request to one domain can use to affect another. Tenant context is carried explicitly through the control plane and the enforcement path, so a configuration change for app.acme.com can never bleed into portal.globex.com.

Isolation also bounds the blast radius of any single mistake. If one tenant ships an over-aggressive rule, or a single custom domain is targeted by a volumetric campaign, the effect is contained to that domain's policy and that tenant's scope. Strict isolation is what makes per-tenant policy safe to offer in the first place.

Per-tenant policy, applied at the edge

Different customers have different needs. An enterprise tenant on a regulated plan may want OWASP CRS running at a higher paranoia level with strict blocking; a smaller tenant may start in detection mode while they tune. ArxLayer expresses policy as versioned, API-first objects scoped to each tenant and bound to each domain. Because protection is built on the OWASP Core Rule Set running on the Coraza engine, per-tenant policy means concrete, transparent controls — anomaly-scoring thresholds, paranoia levels, and targeted exclusions — rather than an opaque on/off switch.

Policy changes flow through an event-driven control plane: a new version is recorded as the durable source of truth, published to the edge, and applied to the matching hostname. Every version is immutable and reversible, so a tenant can move from detection to blocking deliberately and roll back cleanly if a change affects legitimate traffic. Enforcement happens at the edge, before requests reach the customer's origin, which is exactly where a custom-domain attack should be stopped.

Certificates for customer hostnames — without the WAF holding keys

Custom domains require valid TLS certificates, and this is where many designs make a serious mistake: they let the WAF terminate TLS and store the corresponding private keys, turning the traffic-enforcement layer into a sprawling key store full of customer secrets. ArxLayer is built the opposite way. The WAF is traffic enforcement, not a key custodian, and it never holds a private key — for your domains or your customers'.

The workflow separates three concerns cleanly:

• ArxLayer Certificate owns the certificate lifecycle for each customer hostname — issuance, renewal, and rotation — so onboarding a domain does not mean a human chasing a certificate.
• ArxLayer Trust owns key custody. Private keys and trust bundles live behind a dedicated trust boundary, separate from the enforcement path.
• ArxLayer Edge references certificates as opaque values. The enforcement layer receives a certificate reference and metadata, stores it verbatim, and never parses or resolves it to key material.

Critically, no private key ever travels across the event bus that distributes configuration. The bus carries certificate references and metadata only. That means even a full compromise of the WAF layer — or of the config bus — does not yield a single tenant's private key, because those keys are not there to take. This is the same boundary we make the full case for in why a WAF should not own private keys, and it matters far more for custom domains than for your own apex, because you are now responsible for thousands of third-party hostnames at once.

Verify ownership before you serve

A custom hostname must not be served until the tenant has proven they control it. Serving an unverified domain invites tenant confusion and subdomain-takeover attacks, where someone points a hostname at your platform that they do not actually own. The onboarding flow should require a verifiable signal — a DNS record the customer publishes, or an equivalent challenge — confirming that the hostname genuinely belongs to the tenant requesting it before any certificate is issued or any traffic is accepted on that name.

Verification and certificate issuance are deliberately sequenced. Ownership is established first; only then does ArxLayer Certificate provision the certificate, and only then does the edge begin enforcing policy for that hostname. Tying issuance to verified ownership closes the dangling-DNS gap and keeps a half-finished onboarding from ever reaching a live, certificate-backed endpoint.

Onboarding considerations at scale

Because thousands of domains are onboarded without manual steps, the workflow has to be both automatic and observable. A few practical considerations stand out:

• Make every step an API resource. Domains, ownership status, certificate references, and policy versions are all programmable, so onboarding can be driven by your own systems and audited after the fact.
• Default to a safe policy, then tune. A newly verified custom domain can start under a sensible tenant default — frequently OWASP CRS in detection mode — and graduate to blocking once the tenant has reviewed the evidence.
• Keep certificate lifecycle invisible to the tenant. Renewal and rotation are handled by ArxLayer Certificate, with key custody in ArxLayer Trust, so the customer's only job is the initial CNAME and ownership proof.
• Surface freshness and health per hostname. The edge reports config freshness and serves a last-known-good policy if the bus is briefly unavailable, so a transient interruption never drops protection for a customer domain.

The ArxLayer angle

Custom domains let your customers make your product their own — and they hand you responsibility for a large, externally controlled attack surface. ArxLayer is designed for exactly that responsibility: strict multi-tenant isolation, per-tenant OWASP CRS policy enforced at the edge before traffic reaches the origin, and a certificate workflow where lifecycle, key custody, and enforcement are three separate boundaries. The WAF references certificates as opaque values and holds no private keys, so protecting thousands of customer hostnames never turns your enforcement layer into a single high-value key store. To see how the boundaries fit together, read the ArxLayer security model.