Pourquoi l'isolation par domaine personnalisé est une exigence de marché régulé, pas esthétique
Quand un opérateur fait tourner bet.operator.com devant un iframe Sporbet Soft et un opérateur sœur fait tourner bet.competitor.com devant la même infrastructure vendeur, le régulateur au UK, Malte, Suède, Australie ou Ontario ne voit pas un problème vendeur — il voit deux opérateurs dont les postures de sécurité doivent être indépendantes.
Ce cadre réglementaire est pourquoi l'isolation par domaine personnalisé n'est pas une fonctionnalité de marque nice-to-have ; c'est une exigence de conformité structurelle. Chaque surface partenaire — cookies, local storage, CSP, CORS — doit se comporter comme si chaque partenaire était sur sa propre infrastructure dédiée.
Les pièces architecturales qui nous amènent ici sont résumées dans notre anatomie d'intégration.
Self-service de domaine personnalisé et provisionnement SSL automatique
Un opérateur pointant son CNAME bet.operator.com vers l'edge gateway de Sporbet Soft est, aujourd'hui, un flux self-service de cinq minutes dans le partner panel. L'opérateur colle le domaine, choisit la clé API correspondante et le panel guide à travers la validation DNS, le provisionnement TLS et la configuration des en-têtes CSP.
Sous le capot, l'autorité de certification émet un certificat SAN scopé au hostname de l'opérateur. Le certificat est stocké dans la couche de terminaison TLS de notre flotte edge avec le hostname comme clé. La rotation de cert est automatisée sur une cadence de 30 jours.
Sporbet Soft ne stocke jamais les clés privées en dehors du volume chiffré KMS de la couche de terminaison TLS — voir pourquoi l'iframe absorbe cette complexité.
Content-Security-Policy scopé par partenaire
CSP est la primitive d'isolation phare. Chaque réponse que l'iframe sert sur le domaine personnalisé d'un partenaire ship un en-tête CSP scopé à ce partenaire — default-src 'self', script-src 'self', connect-src 'self' wss://gw.sporbetsoft.com, frame-ancestors https://*.operator.com.
La directive frame-ancestors est celle qui porte la charge. Elle dit au navigateur quelles origines parent peuvent intégrer l'iframe ; un opérateur définissant frame-ancestors https://*.operator.com garantit que l'iframe refusera de rendre si un site tiers essaie de le clickjacker.
Quand un opérateur ajoute un nouveau sous-domaine marketing — disons promo.operator.com — il met à jour frame-ancestors via le panel, et la nouvelle politique est en vigueur à la toute prochaine requête. Pas de déploiement, pas de ticket, pas d'attente.
X-Frame-Options, COOP et l'attribut sandbox
X-Frame-Options est le cousin legacy de frame-ancestors et nous l'expédions encore pour les navigateurs plus anciens. L'en-tête est défini à SAMEORIGIN sur les réponses HTML de l'iframe par défaut.
Cross-Origin-Opener-Policy est l'en-tête moderne plus intéressant. L'iframe Sporbet Soft ship Cross-Origin-Opener-Policy: same-origin-allow-popups, qui isole le contexte de navigation de l'iframe de la page parent de l'opérateur tout en permettant à l'iframe d'ouvrir des popups OAuth-style pour les fournisseurs KYC.
L'attribut sandbox de l'iframe peut, quand l'opérateur veut une isolation supplémentaire, être défini à sandbox="allow-scripts allow-same-origin allow-popups allow-forms".
Allow-list CORS et la vérification d'origine WebSocket
CORS est l'endroit où les plateformes multi-tenant glissent le plus souvent. La tentation est de définir Access-Control-Allow-Origin: * sur les endpoints API du vendeur. Cela fonctionne pour un tenant et casse méchamment pour beaucoup.
Les API de Sporbet Soft honorent une allow-list CORS stricte par partenaire dérivée des domaines configurés du partenaire. Une requête depuis https://promo.operator.com ne réussit contre les endpoints partenaire-A que si promo.operator.com est sur l'allow-list du partenaire A.
La même allow-list régit la vérification d'origine WebSocket. Notre gateway WebSocket inspecte l'en-tête Origin sur la requête d'upgrade et rejette les connexions des origines non correspondantes avec HTTP 403 — voir notre architecture de latence des cotes.
Ce que l'auditeur vérifie réellement
Quand un auditeur UKGC, MGA, Spelinspektionen, ACMA ou AGCO review Sporbet Soft en tant que vendeur B2B au nom d'un opérateur, le script est prévisible. Ils tirent l'iframe sur le domaine personnalisé de l'opérateur, dumpent chaque en-tête de réponse, parcourent CSP et COOP/COEP, dumpent les cookies, dumpent le local storage.
L'audit parcourt aussi la discipline opérationnelle : comment le domaine d'un partenaire est-il ajouté ? Qui a accès au partner panel ? Comment les actions admin sont-elles loggées ? Chez Sporbet Soft les réponses sont : via le flux self-service avec validation DNS+CSP ; seulement les utilisateurs du panel scopés par rôle de l'opérateur ; chaque action admin émet un événement d'audit immuable.
Les opérateurs atterrissant dans des marchés régulés partagent typiquement cet article avec leur auditeur pendant la phase de procurement. Voir vue d'ensemble iframe et tarification.