Warum Custom-Domain-Isolation eine regulierte-Markt-Anforderung ist, keine ästhetische
Wenn ein Operator bet.operator.com vor einem Sporbet-Soft-iframe betreibt und ein Schwester-Operator bet.competitor.com vor derselben Vendor-Infrastruktur betreibt, sieht der Regulator in UK, Malta, Schweden, Australien oder Ontario kein Vendor-Problem — er sieht zwei Operatoren, deren Sicherheits-Postures unabhängig sein müssen.
Dieses regulatorische Framing ist, warum Custom-Domain-Isolation kein Nice-to-have-Brand-Feature ist, sondern eine strukturelle Compliance-Anforderung. Jede partner-facing Oberfläche — Cookies, Local Storage, CSP, CORS — muss sich so verhalten, als wäre jeder Partner auf seiner eigenen dedizierten Infrastruktur.
Die architektonischen Teile, die uns hierher bringen, sind in unserer Integrations-Anatomie zusammengefasst.
Custom-Domain-Self-Service und automatische SSL-Provisionierung
Ein Operator, der seinen bet.operator.com-CNAME auf das Edge-Gateway von Sporbet Soft zeigt, ist heute ein fünfminütiger Self-Service-Flow im Partner-Panel. Der Operator fügt die Domain ein, wählt den passenden API-Key aus und das Panel führt durch DNS-Validierung, TLS-Provisionierung und CSP-Header-Konfiguration.
Unter der Haube stellt die Zertifizierungsstelle ein SAN-Zertifikat aus, gescoped auf den Hostname des Operators. Das Zertifikat wird in der TLS-Termination-Schicht unserer Edge-Flotte mit Hostname als Schlüssel gespeichert. Cert-Rotation ist im 30-Tage-Rhythmus automatisiert.
Sporbet Soft speichert private Keys niemals außerhalb des KMS-verschlüsselten Volumes der TLS-Termination-Schicht — siehe warum iframe diese Komplexität absorbiert.
Content-Security-Policy pro Partner gescoped
CSP ist das Headline-Isolation-Primitive. Jede Response, die der iframe auf der Custom-Domain eines Partners ausliefert, ship einen CSP-Header gescoped auf diesen Partner — default-src 'self', script-src 'self', connect-src 'self' wss://gw.sporbetsoft.com, frame-ancestors https://*.operator.com.
Die frame-ancestors-Direktive ist die tragende. Sie sagt dem Browser, welche Parent-Origins den iframe einbetten dürfen; ein Operator, der frame-ancestors https://*.operator.com setzt, stellt sicher, dass der iframe sich weigert zu rendern, wenn eine Drittseite ihn clickjackt.
Wenn ein Operator eine neue Marketing-Subdomain hinzufügt — sagen wir promo.operator.com — aktualisieren sie die frame-ancestors über das Panel, und die neue Policy ist beim allernächsten Request wirksam. Kein Deploy, kein Ticket, kein Warten.
X-Frame-Options, COOP und das Sandbox-Attribut
X-Frame-Options ist der Legacy-Cousin von frame-ancestors und wir liefern es weiter für ältere Browser. Der Header wird auf den HTML-Responses des iframes standardmäßig auf SAMEORIGIN gesetzt.
Cross-Origin-Opener-Policy ist der interessantere moderne Header. Sporbet Softs iframe ship Cross-Origin-Opener-Policy: same-origin-allow-popups, was den Browsing-Kontext des iframes von der Parent-Seite des Operators isoliert und gleichzeitig dem iframe erlaubt, OAuth-Style-Popups für KYC-Anbieter zu öffnen.
Das sandbox-Attribut des iframes kann, wenn der Operator zusätzliche Isolation wünscht, auf sandbox="allow-scripts allow-same-origin allow-popups allow-forms" gesetzt werden.
CORS-Allow-List und der WebSocket-Origin-Check
CORS ist der Ort, an dem Multi-Tenant-Plattformen am häufigsten ausrutschen. Die Versuchung ist, Access-Control-Allow-Origin: * auf den API-Endpoints des Vendors zu setzen, damit Partner-Storefronts von überall zurück in die Plattform rufen können. Das funktioniert für einen Tenant und bricht schlimm für viele.
Sporbet Softs APIs respektieren eine strikte Per-Partner-CORS-Allow-List, abgeleitet von den konfigurierten Domains des Partners. Ein Request von https://promo.operator.com ist nur erfolgreich gegen Partner-A-Endpoints, wenn promo.operator.com auf der Allow-List von Partner A steht.
Dieselbe Allow-List regelt den WebSocket-Origin-Check. Unser WebSocket-Gateway inspiziert den Origin-Header auf der Upgrade-Anfrage und lehnt Connections aus nicht passenden Origins mit HTTP 403 ab — siehe unsere Quoten-Latenz-Architektur.
Was der Auditor tatsächlich prüft
Wenn ein UKGC-, MGA-, Spelinspektionen-, ACMA- oder AGCO-Auditor Sporbet Soft als B2B-Vendor im Auftrag eines Operators reviewt, ist das Skript vorhersehbar. Sie ziehen den iframe über die Custom-Domain des Operators, dumpen jeden Response-Header, gehen durch CSP und COOP/COEP, dumpen die Cookies, dumpen den Local Storage.
Das Audit geht auch durch die operative Disziplin: Wie wird die Domain eines Partners hinzugefügt? Wer hat Zugriff auf das Partner-Panel? Wie werden Admin-Aktionen geloggt? Bei Sporbet Soft sind die Antworten: über den Self-Service-Flow mit DNS+CSP-Validierung; nur die rollen-scoped Panel-User des Operators; jede Admin-Aktion emittiert ein immutables Audit-Event.
Operatoren, die in regulierten Märkten landen, teilen typischerweise diesen Artikel und das entsprechende Sicherheits-Runbook mit ihrem Auditor während der Procurement-Phase. Siehe iframe-Übersicht und Preise.