Por qué el aislamiento por dominio personalizado es un requisito de mercado regulado, no estético
Cuando un operador corre bet.operator.com delante de un iframe Sporbet Soft y un operador hermano corre bet.competitor.com delante de la misma infraestructura del vendor, el regulador en UK, Malta, Suecia, Australia u Ontario no ve un problema de vendor — ve dos operadores cuyas posturas de seguridad deben ser independientes.
Ese encuadre regulatorio es por qué el aislamiento por dominio personalizado no es solo una característica de marca nice-to-have; es un requisito de cumplimiento estructural. Cada superficie partner — cookies, local storage, CSP, CORS — debe comportarse como si cada partner estuviera en su propia infraestructura dedicada.
Las piezas arquitectónicas que nos llevan aquí están resumidas en nuestra anatomía de integración.
Self-service de dominio personalizado y aprovisionamiento SSL automático
Un operador apuntando su CNAME bet.operator.com al edge gateway de Sporbet Soft es, hoy, un flujo self-service de cinco minutos dentro del partner panel. El operador pega el dominio, elige la API key correspondiente y el panel guía a través de validación DNS, aprovisionamiento TLS y configuración de headers CSP.
Bajo el capó, la autoridad de certificación emite un certificado SAN scoped al hostname del operador. El certificado se almacena en la capa de terminación TLS de nuestra flota edge con hostname como clave. La rotación de cert está automatizada en una cadencia de 30 días.
Sporbet Soft nunca almacena claves privadas fuera del volumen cifrado por KMS de la capa de terminación TLS — ver por qué el iframe absorbe esta complejidad.
Content-Security-Policy scoped por partner
CSP es la primitiva de aislamiento principal. Cada respuesta que el iframe sirve en el dominio personalizado de un partner envía un header CSP scoped a ese partner — default-src 'self', script-src 'self', connect-src 'self' wss://gw.sporbetsoft.com, frame-ancestors https://*.operator.com.
La directiva frame-ancestors es la que carga el peso. Le dice al navegador qué orígenes parent pueden incrustar el iframe; un operador estableciendo frame-ancestors https://*.operator.com asegura que el iframe rechazará renderizar si un sitio de terceros intenta clickjackerlo.
Cuando un operador agrega un nuevo subdominio de marketing — digamos promo.operator.com — actualiza frame-ancestors a través del panel, y la nueva política está en efecto en la siguiente request. Sin deploy, sin ticket, sin esperar.
X-Frame-Options, COOP y el atributo sandbox
X-Frame-Options es el primo legacy de frame-ancestors y todavía lo enviamos para navegadores más antiguos. El header se establece a SAMEORIGIN en las respuestas HTML del iframe por defecto.
Cross-Origin-Opener-Policy es el header moderno más interesante. El iframe de Sporbet Soft envía Cross-Origin-Opener-Policy: same-origin-allow-popups, que aísla el contexto de navegación del iframe de la página parent del operador mientras permite al iframe abrir popups estilo OAuth para proveedores KYC.
El atributo sandbox del iframe puede, cuando el operador quiere aislamiento adicional, establecerse a sandbox="allow-scripts allow-same-origin allow-popups allow-forms".
Allow-list CORS y la verificación de origen WebSocket
CORS es donde las plataformas multi-tenant más a menudo resbalan. La tentación es establecer Access-Control-Allow-Origin: * en los endpoints API del vendor. Eso funciona para un tenant y se rompe mal para muchos.
Las APIs de Sporbet Soft honran una estricta allow-list CORS por partner derivada de los dominios configurados del partner. Una request desde https://promo.operator.com solo tiene éxito contra los endpoints partner-A si promo.operator.com está en la allow-list del partner A.
La misma allow-list rige la verificación de origen WebSocket. Nuestro gateway WebSocket inspecciona el header Origin en la request de upgrade y rechaza conexiones desde orígenes no coincidentes con HTTP 403 — ver nuestra arquitectura de latencia de cuotas.
Qué verifica realmente el auditor
Cuando un auditor UKGC, MGA, Spelinspektionen, ACMA o AGCO revisa Sporbet Soft como vendor B2B en nombre de un operador, el script es predecible. Sacan el iframe sobre el dominio personalizado del operador, vuelcan cada header de respuesta, recorren CSP y COOP/COEP, vuelcan las cookies, vuelcan el local storage.
La auditoría también recorre la disciplina operacional: ¿cómo se agrega el dominio de un partner? ¿Quién tiene acceso al partner panel? ¿Cómo se loggean las acciones admin? En Sporbet Soft las respuestas son: a través del flujo self-service con validación DNS+CSP; solo los usuarios del panel scoped por rol del operador; cada acción admin emite un evento de auditoría inmutable.
Los operadores aterrizando en mercados regulados típicamente comparten este artículo con su auditor durante la fase de procurement. Ver visión general del iframe y precios.