Los requisitos de integridad para una app de iGaming deben definir qué señales de la aplicación y del dispositivo presenta un cliente nativo, cómo las verifica el backend y qué puede cambiar cada resultado para una acción sensible. Un veredicto de atestación es una evidencia de riesgo útil, pero no demuestra la identidad, ubicación, elegibilidad ni intención del jugador.
Para un CTO de operador, responsable de producto móvil, líder de seguridad de aplicaciones, fraude o lanzamientos, o comprador de compras, la decisión consiste en ubicar la evidencia de integridad en el recorrido del jugador sin convertir un servicio de plataforma en la autoridad sobre el estado de la cuenta o de la apuesta. El entregable útil es un paquete versionado de políticas de integridad que una el inventario de señales, el contrato de verificación del servidor, la matriz de respuestas por acción, las vías de excepción, los controles de despliegue y las pruebas de aceptación.
Trate la integridad como evidencia y no como autoridad
La evidencia de integridad de la app debe cambiar la confianza asociada a una solicitud, no sustituir la autenticación, la autorización, los controles de fraude ni las reglas de transacción del servidor. Apple describe App Attest como una forma de que una instancia legítima de la app respalde decisiones más fiables sobre el acceso a recursos sensibles del servidor, pero también advierte que ninguna política por sí sola elimina todo el fraude y que App Attest no puede identificar de manera definitiva todos los sistemas operativos comprometidos.
Google presenta de forma similar los veredictos de Play Integrity para binarios reconocidos, licencias y entornos de dispositivo. Su documentación indica que la API funciona mejor junto con otras señales contra el abuso y no como mecanismo único. La consecuencia arquitectónica es directa: un veredicto válido no autoriza un retiro, no acepta una apuesta ni prueba quién sostiene el dispositivo. El backend sigue evaluando la cuenta autenticada, la sesión actual, la acción, el recurso, el mercado y el estado de la plataforma.
Escriba esos límites en los requisitos. Distinga la autenticidad de la app, el canal de instalación, el entorno del dispositivo y la actividad reciente de la identidad del jugador, la geolocalización, el estado de la cuenta y la validez de la transacción. Un control es más fácil de probar cuando cada señal tiene un significado declarado y una lista explícita de decisiones que no puede tomar.
Mapee las acciones sensibles antes de elegir una API de atestación
Una política de integridad debe comenzar por las acciones sensibles y las amenazas antes de comenzar por los métodos de Apple o Android. Inventaríe el inicio de sesión, el registro de autenticadores, la recuperación, los cambios de instrumentos de pago, los depósitos, los retiros, el envío de apuestas, las solicitudes de bonos, el acceso a datos personales, el registro de dispositivos y los cambios de cuenta asistidos por soporte cuando esos recorridos existan en el producto.
Para cada acción, registre el activo protegido, el abuso probable, la presencia de usuario requerida, las demás señales disponibles, la latencia aceptable y la consecuencia de un falso positivo. Después decida si la evidencia de integridad se necesita durante el registro, una vez por instancia de la app, periódicamente o justo antes de un comando de alto riesgo. Solicitar un veredicto en cada pantalla puede añadir coste y modos de fallo sin mejorar la decisión.
Los requisitos de seguridad para el juego remoto de Gran Bretaña se aplican a sistemas críticos que manejan información de autenticación, saldos de cuentas y puntos de entrada o salida de esos sistemas. También señalan los dispositivos de usuario, la protección contra malware, el desarrollo seguro, la seguridad de aplicaciones, las pruebas y la gestión de cambios entre las áreas de control relevantes. Es un alcance específico de esa jurisdicción, no una regla que exija un producto concreto de atestación móvil, pero respalda la trazabilidad entre los requisitos de integridad y el recorrido crítico que protegen.
Verifique las afirmaciones en el servidor y vincúlelas a la solicitud
Las afirmaciones de integridad deben verificarse en el backend y vincularse a la solicitud actual para que un resultado capturado no pueda reutilizarse como aprobación de otra acción. El cliente puede recopilar evidencia de la plataforma, pero no puede ser el juez final de una evidencia destinada a detectar un cliente modificado.
La documentación de validación en el servidor de Apple utiliza un reto único y de un solo uso emitido por el servidor en el flujo de atestación o afirmación. El servidor valida la cadena de certificados y la identidad de la app, guarda la clave pública verificada para la instancia, comprueba los datos firmados del cliente y avanza el contador de afirmaciones. Google exige enviar los tokens de Play Integrity al backend para su descifrado y verificación antes de que el backend decida cómo responder.
Defina el contrato de datos alrededor de un identificador estable de la acción, el contexto de cuenta y sesión, la versión de la app, la plataforma, el reto, la hora de emisión, la caducidad, la acción solicitada y la versión de la política. Mantenga la evidencia bruta de la plataforma fuera de la analítica y las vistas habituales de soporte salvo que una necesidad revisada la exija. Registre la decisión normalizada y la evidencia mínima necesaria para explicarla sin convertir la telemetría de seguridad en un expediente de dispositivo sin control.
Use una matriz de respuestas por acción en vez de un bloqueo global
Una matriz de respuestas de integridad debe definir un resultado proporcional para cada combinación de acción y estado de la evidencia. Los estados normalizados útiles pueden incluir verificado, fallido, no disponible, no compatible, obsoleto y servicio degradado, pero la implementación debe conservar las diferencias que expone cada plataforma.
La respuesta puede permitir una lectura de bajo riesgo, solicitar evidencia nueva, exigir una nueva autenticación, restringir una acción de alto riesgo, enviar un caso a revisión o denegar un comando cuando el modelo de amenazas y la política aplicable lo justifiquen. No convierta silenciosamente una interrupción de infraestructura en una acusación de fraude. Tampoco permita que una alternativa permisiva vuelva decorativa la evidencia de integridad.
El estándar de resiliencia móvil de OWASP describe los controles contra la manipulación y de integridad de plataforma como defensa en profundidad. También advierte que las comprobaciones específicas de una plataforma pueden excluir a usuarios legítimos, generar falsos positivos o aumentar la dependencia, y afirma que la resiliencia no debe sustituir la arquitectura segura ni la validación del servidor. Una matriz revisable hace visibles esas compensaciones para producto, seguridad, fraude, soporte y cumplimiento antes de que el código las decida de forma implícita.
Diseñe los estados no disponibles y no compatibles como recorridos reales
Los controles de integridad deben tener recorridos explícitos para dispositivos no compatibles, servicios de plataforma ausentes, fallos de red, limitación de solicitudes, claves obsoletas e interrupciones de la verificación del backend. Son estados operativos esperables, no casos extremos que puedan compartir un error genérico.
Apple expone si App Attest es compatible y recomienda una incorporación gradual en producción. Su documentación de preparación separa las claves de sandbox y producción y advierte a los equipos que gestionen límites de solicitudes dinámicos. Google recomienda planificar cómo se comporta el backend durante una interrupción de Play Integrity o una revocación de claves de dispositivo y ofrecer un mensaje útil cuando el usuario pueda reintentar o corregir una condición del dispositivo.
Defina qué acciones siguen disponibles, cuáles necesitan otra vía verificada y cuáles deben esperar. Conserve un acceso adecuado a soporte y recuperación de la cuenta sin prometer que todas las acciones sensibles puedan continuar. La guía de implementación de passkeys explica los límites de autenticación, autenticación reforzada y recuperación que la evidencia de integridad puede informar, pero no sustituir.
Despliegue en etapas de observación evaluación y aplicación
La aplicación de políticas de integridad debe comenzar con una etapa exclusiva de observación que mida la disponibilidad de los veredictos y el impacto de la política sin cambiar silenciosamente los resultados para el jugador. Google recomienda expresamente recopilar telemetría y comprender a la audiencia existente antes de actuar sobre los veredictos de Play Integrity. Apple recomienda una incorporación gradual para que una gran base instalada no provoque un aumento evitable de solicitudes de atestación.
Defina la cohorte, la duración, los estados de evidencia esperados, la revisión de privacidad, la vía de investigación de falsos positivos y el responsable de la decisión antes de comenzar la observación. Evalúe los resultados por versión de la app, categoría de plataforma compatible, recorrido y acción, en lugar de tratar una tasa total de fallos como una verdad del producto. Después active respuestas de alcance reducido mediante una política versionada del servidor que pueda detenerse de forma independiente de un lanzamiento en la tienda.
El plan de despliegue también debe indicar cómo cambia o retira una regla el equipo. Un lanzamiento en una tienda puede dejar activas varias versiones de la app al mismo tiempo, por lo que la compatibilidad del backend y el versionado de políticas deben cubrir la ventana de versiones admitidas. La guía de gobernanza de SDK de terceros ofrece los controles adyacentes de inventario y retirada cuando una implementación de integridad incorpora código de un proveedor.
Acepte el control contra una versión exacta de la app
Un paquete de aceptación de integridad debe vincular la política, la configuración de plataforma, el verificador del servidor y la evidencia de prueba a una versión móvil exacta y a una versión de la política del backend. Una captura de pantalla correcta o un solo token válido no bastan para demostrar que las vías de repetición, degradación, interrupción y falsos positivos funcionan como se diseñaron.
Exija el inventario de amenazas y acciones, la matriz de capacidades por plataforma, los identificadores registrados de la app, la separación de entornos, la propiedad de claves y credenciales, la lógica de verificación del servidor, la vida del reto, las defensas contra repetición, los estados normalizados, la matriz de respuestas, los mensajes al usuario, los campos de observabilidad, las reglas de conservación, el manual de soporte, el plan de despliegue gradual, las aprobaciones de excepciones y el procedimiento de reversión. Pruebe compilaciones válidas y alteradas cuando exista autorización, identificadores incorrectos, retos reutilizados, afirmaciones obsoletas, dispositivos no compatibles, pérdida de conectividad, interrupción del proveedor, rotación de claves y cambios simultáneos de política o versión.
El paquete no puede demostrar que el cliente nunca se modificará ni que un veredicto de la plataforma siempre estará disponible. Ofrece al comprador una respuesta reproducible sobre qué evidencia produce la versión exacta, cómo la interpreta el backend y qué sucede cuando la evidencia falta o es adversa.
Para equipos que encargan un producto nativo orientado al jugador, el desarrollo de aplicaciones de Wizards puede convertir los recorridos sensibles, la evidencia de plataforma y las decisiones del servidor en un contrato de integridad y un paquete de aceptación del lanzamiento.
Preguntas frecuentes
¿Qué deben incluir los requisitos de integridad de una app de iGaming?
Los requisitos de integridad de una app de iGaming deben incluir las acciones protegidas, las señales de plataforma, la verificación del servidor, los controles de retos y repetición, los estados normalizados de evidencia, la matriz de respuestas, las vías de excepción, las etapas de despliegue, los mensajes al usuario y las pruebas vinculadas a la versión.
¿Un veredicto de integridad válido demuestra que el jugador es legítimo?
No. Un veredicto de integridad válido puede aumentar la confianza en una instancia de la app o en el entorno del dispositivo, pero no demuestra la identidad, ubicación, elegibilidad, estado de cuenta ni intención del jugador. Esas decisiones todavía necesitan su propia evidencia fiable y controles del servidor.
¿Dónde deben verificarse App Attest o Play Integrity?
La evidencia de App Attest y Play Integrity debe verificarse en un backend de confianza. El servidor debe vincular el resultado al reto actual, la identidad y versión de la app, la sesión y la acción solicitada antes de aplicar una política versionada.
¿Debe una app de iGaming bloquear cada comprobación de integridad fallida?
No. La respuesta debe seguir el riesgo de la acción y el significado del estado de la evidencia. Una política puede permitir, reintentar, reforzar la autenticación, restringir, revisar o denegar, mientras distingue un veredicto fallido de un servicio no disponible, no compatible, obsoleto o degradado.
¿Cómo debe desplegarse la aplicación de políticas de integridad?
La aplicación de políticas de integridad debe comenzar con observación controlada, revisión del impacto y una política gradual de alcance reducido. El equipo debe medir los dispositivos compatibles, la disponibilidad de evidencia, los falsos positivos y los fallos del servicio antes de ampliar la aplicación.
¿Qué evidencia debe entregar un proveedor de integridad de apps?
Un proveedor de integridad de apps debe entregar la configuración exacta de plataforma, el contrato de verificación del servidor, la matriz de amenazas y acciones, las defensas contra repetición, el comportamiento ante fallos, la telemetría, los procedimientos de despliegue y soporte, las pruebas negativas y la evidencia vinculada a las versiones aceptadas de la app y del backend.
