Por que o isolamento por domínio personalizado é um requisito de mercado regulado, não estético
Quando um operador roda bet.operator.com na frente de um iframe Sporbet Soft e um operador irmão roda bet.competitor.com na frente da mesma infraestrutura do vendor, o regulador no UK, Malta, Suécia, Austrália ou Ontário não vê um problema do vendor — vê dois operadores cujas posturas de segurança devem ser independentes.
Esse enquadramento regulatório é por que o isolamento por domínio personalizado não é só uma feature de marca nice-to-have; é um requisito de compliance estrutural. Cada superfície parceiro — cookies, local storage, CSP, CORS — deve se comportar como se cada parceiro estivesse em sua própria infraestrutura dedicada.
As peças arquitetônicas que nos levam aqui estão resumidas em nossa anatomia de integração.
Self-service de domínio personalizado e provisionamento SSL automático
Um operador apontando seu CNAME bet.operator.com para o edge gateway da Sporbet Soft é, hoje, um fluxo self-service de cinco minutos dentro do partner panel. O operador cola o domínio, escolhe a API key correspondente e o panel guia através de validação DNS, provisionamento TLS e configuração de headers CSP.
Sob o capô, a autoridade certificadora emite um certificado SAN com escopo no hostname do operador. O certificado é armazenado na camada de terminação TLS da nossa frota edge com hostname como chave. A rotação de cert é automatizada em uma cadência de 30 dias.
Sporbet Soft nunca armazena chaves privadas fora do volume criptografado por KMS da camada de terminação TLS — ver por que o iframe absorve essa complexidade.
Content-Security-Policy com escopo por parceiro
CSP é a primitiva de isolamento principal. Cada resposta que o iframe serve no domínio personalizado de um parceiro envia um header CSP com escopo nesse parceiro — default-src 'self', script-src 'self', connect-src 'self' wss://gw.sporbetsoft.com, frame-ancestors https://*.operator.com.
A diretiva frame-ancestors é a que carrega o peso. Diz ao navegador quais origens parent têm permissão para embedar o iframe; um operador definindo frame-ancestors https://*.operator.com garante que o iframe se recusará a renderizar se um site de terceiros tentar clickjackeá-lo.
Quando um operador adiciona um novo subdomínio de marketing — digamos promo.operator.com — eles atualizam frame-ancestors através do panel, e a nova política está em efeito na próxima request. Sem deploy, sem ticket, sem esperar.
X-Frame-Options, COOP e o atributo sandbox
X-Frame-Options é o primo legacy de frame-ancestors e ainda enviamos para navegadores mais antigos. O header é definido como SAMEORIGIN nas respostas HTML do iframe por padrão.
Cross-Origin-Opener-Policy é o header moderno mais interessante. O iframe da Sporbet Soft envia Cross-Origin-Opener-Policy: same-origin-allow-popups, que isola o contexto de navegação do iframe da página parent do operador enquanto ainda permite que o iframe abra popups estilo OAuth para provedores KYC.
O atributo sandbox do iframe pode, quando o operador quer isolamento adicional, ser definido como sandbox="allow-scripts allow-same-origin allow-popups allow-forms".
Allow-list CORS e a verificação de origem WebSocket
CORS é onde plataformas multi-tenant mais frequentemente escorregam. A tentação é definir Access-Control-Allow-Origin: * nos endpoints API do vendor. Isso funciona para um tenant e quebra feio para muitos.
As APIs da Sporbet Soft honram uma allow-list CORS estrita por parceiro derivada dos domínios configurados do parceiro. Uma request de https://promo.operator.com só tem sucesso contra os endpoints parceiro-A se promo.operator.com estiver na allow-list do parceiro A.
A mesma allow-list governa a verificação de origem WebSocket. Nosso gateway WebSocket inspeciona o header Origin na request de upgrade e rejeita conexões de origens não correspondentes com HTTP 403 — ver nossa arquitetura de latência de odds.
O que o auditor realmente verifica
Quando um auditor UKGC, MGA, Spelinspektionen, ACMA ou AGCO revisa Sporbet Soft como vendor B2B em nome de um operador, o script é previsível. Eles puxam o iframe sobre o domínio personalizado do operador, despejam cada header de resposta, percorrem CSP e COOP/COEP, despejam os cookies, despejam o local storage.
A auditoria também percorre a disciplina operacional: como o domínio de um parceiro é adicionado? Quem tem acesso ao partner panel? Como ações admin são logadas? Na Sporbet Soft as respostas são: através do fluxo self-service com validação DNS+CSP; apenas os usuários do panel com escopo de role do operador; cada ação admin emite um evento de auditoria imutável.
Operadores pousando em mercados regulados tipicamente compartilham este artigo com seu auditor durante a fase de procurement. Ver visão geral do iframe e preços.