Un juego de navegador seguro comienza con un límite claro: todo lo que se entrega al jugador es inspeccionable y potencialmente modificable, mientras que las cuentas, apuestas y resultados autorizados permanecen en sistemas de servidores confiables. Los controles del navegador, como la Política de seguridad de contenido, la integridad de los subrecursos y Trusted Types, reducen las rutas de ataque específicas del lado del cliente dentro de ese modelo más grande.
Estos controles se complementan entre sí. CSP restringe lo que el documento puede cargar o ejecutar. SRI verifica que los recursos externos seleccionados coincidan con un resumen criptográfico esperado. Trusted Types puede restringir los peligrosos sumideros de inyección DOM a valores producidos por políticas aprobadas. Ninguno convierte el código del cliente en un secreto y ninguno compensa una decisión autorizada dejada en el navegador.
Asigne primero cada ejecutable y origen de red
Una política debe comenzar con un inventario de lo que realmente carga el juego: su documento, scripts, trabajadores, módulos WebAssembly, texturas, fuentes, audio, conexiones API, telemetría y marcos integrados. Registre el propietario y el propósito de cada origen. Una dependencia desconocida no puede recibir un permiso deliberado.
Reduzca la lista antes de codificarla en CSP. Hospede automáticamente los activos estables cuando corresponda, elimine los rastreadores no utilizados y mantenga los puntos finales de desarrollo fuera de la configuración de producción. Los comodines amplios hacen que una política sea más fácil de implementar pero más débil como límite de aplicación.
Trate el código de terceros como código, incluso cuando llegue a través de análisis o un administrador de etiquetas. Un script confiable puede manipular el documento dentro de las capacidades que le brinda la página. Si una dependencia solo necesita datos de eventos, prefiera una integración estrecha del lado del servidor o un marco aislado en lugar de la ejecución sin restricciones del documento principal cuando la arquitectura del producto lo permita.
Construya CSP alrededor de nonces o hashes
Guía CSP de MDN explica cómo el encabezado de respuesta puede restringir los tipos de recursos y la ejecución de scripts. Una política moderna y estricta normalmente autoriza los scripts de aplicación previstos con nonces por respuesta o hashes de tiempo de compilación en lugar de mantener una larga lista de hosts.
Comience en modo Content-Security-Policy-Report-Only, recopile infracciones, elimine dependencias inesperadas y luego aplique la política. La presentación de informes es una ayuda para la migración, no una razón para dejar inhabilitada la aplicación de la ley. Filtre datos confidenciales de los informes y espere ruido de las extensiones del navegador o del software local inyectado.
Evite unsafe-inline y unsafe-eval a menos que una restricción de compatibilidad medida y documentada los requiera. Algunos motores de juegos o paquetes heredados compilan código dinámicamente; ese comportamiento debe identificarse durante la auditoría de compilación, no descubrirse cuando la aplicación llega a producción.
Separe las directivas por capacidad. script-src, connect-src, img-src, font-src, worker-src y frame-src responden a diferentes preguntas. Un juego que abre conexiones WebSocket o crea trabajadores necesita esos puntos finales declarados sin otorgar el mismo permiso de origen a los scripts.
Utilice SRI para recursos externos inmutables
Integridad de los subrecursos permite que un enlace script o una hoja de estilo declare uno o más resúmenes criptográficos. El navegador aplica un hash al recurso obtenido y rechaza una respuesta que no coincide. Esto resulta útil cuando se espera que un activo alojado externamente sea inmutable.
SRI no es una gestión automática de dependencias. Cada cambio de recurso aprobado requiere metadatos de integridad coincidentes, y las recuperaciones de SRI entre orígenes también dependen de que el servidor remoto permita la solicitud a través de CORS. Si un proveedor ofrece contenido cambiante desde una URL, fijar un resumen romperá correctamente ese comportamiento; la integración debe pasar a un artefacto versionado o a un modelo de confianza diferente.
Genere valores de integridad a partir del artefacto de lanzamiento, no una copia del desarrollador, y pruebe la respuesta implementada. La transformación de contenido mediante un proxy o CDN cambia los bytes y debería provocar que falle la verificación. Conserve el artefacto y su resumen como evidencia de publicación para que un incidente pueda conectar la página con la dependencia exacta que esperaba.
Utilice Trusted Types para reducir las rutas de inyección de DOM
Trusted Types apunta a las API DOM que pueden interpretar cadenas como HTML o script. Cuando la aplicación está habilitada, los receptores protegidos aceptan valores escritos creados por políticas registradas en lugar de cadenas arbitrarias. Esto convierte las decisiones de inyección dispersas en un conjunto más pequeño de transformaciones revisables.
El documento W3C Trusted Types es un borrador de trabajo, no una recomendación final. Se debe verificar la compatibilidad del navegador para la matriz de dispositivos del producto y sigue siendo necesaria una construcción DOM segura. La migración correcta es eliminar primero la construcción innecesaria de cadenas HTML y luego colocar plantillas o desinfección revisadas detalladamente detrás de las políticas nombradas.
No cree una política predeterminada que devuelva ciegamente cada entrada. Eso satisface una forma de API al tiempo que preserva la vulnerabilidad. Cada política debe tener un propósito, una procedencia de entrada clara y pruebas con cargas útiles maliciosas.
Mantenga la autoridad y los secretos del juego en el servidor.
CSP, SRI y Trusted Types protegen la ejecución de documentos; no hacen que el saldo, el resultado RNG, el derecho o la clave de firma sean confiables cuando se almacenan en el cliente. Tanto JavaScript como WebAssembly se ejecutan en un entorno controlado por el jugador.
El cliente puede generar un resultado y rechazar entradas obviamente mal formadas para su uso, pero el servidor debe autenticar la sesión, validar las acciones permitidas y su propio estado autoritativo. Utilice credenciales de ámbito breve y cookies o tokens seguros estándar apropiados para la arquitectura. Nunca envíe una clave privada reutilizable, una credencial de base de datos o un token de servicio privilegiado en un paquete.
Este mismo límite informa a Uso de WebAssembly en juegos de casino: la compilación cambia la representación, no la confianza. También pertenece a la etapa de diseño de desarrollo de juegos de casino, antes de que las integraciones de terceros acumulen privilegios implícitos.
Convierta las infracciones de políticas en una puerta de liberación
Automatice las comprobaciones de los encabezados de producción, el comportamiento nonce o hash, las fallas de SRI y la ejecución en línea prohibida. Ejercite el inicio de sesión, la carga del juego, los trabajadores, las llamadas a la API y las rutas de error según la política aplicada. Una página de inicio que pasa mientras el juego pierde silenciosamente a su trabajador no es una implementación exitosa.
Mantenga un pequeño conjunto de pruebas negativas intencionales. Modifique un recurso anclado y confirme que SRI lo bloquea. Intente una conexión no aprobada y confirme que CSP lo informa y lo impide. Pase una cadena que no sea de confianza a un receptor protegido y confirme que la aplicación la rechace. Una puerta de seguridad que nunca ha demostrado fallar aún no es una evidencia.
Revise el inventario de origen con cada nuevo proveedor, actualización del motor y host de activos. Las políticas decaen cuando los equipos agregan excepciones sin eliminar las obsoletas. La política más segura es la más estrecha que respalda el comportamiento de producción verificado.
Preguntas frecuentes
¿Qué hace la Política de seguridad de contenido para un juego de navegador?
La política de seguridad de contenido le dice al navegador qué fuentes y patrones de ejecución puede usar una página. Una política estricta puede reducir las rutas a través de las cuales el contenido inyectado se vuelve ejecutable, pero no reemplaza la codificación de salida ni el diseño seguro de la aplicación.
¿Qué es la integridad de los subrecursos?
Subresource Integrity permite que una página proporcione un hash criptográfico para un script u hoja de estilo recuperados. El navegador compara la respuesta con ese hash y se niega a utilizar un recurso que no coincida.
¿Qué son los Trusted Types?
Trusted Types es una API de navegador para restringir los peligrosos sumideros de inyección DOM a valores creados por políticas aprobadas. El documento W3C aún es un borrador de trabajo, por lo que los equipos deben verificar la compatibilidad del navegador y mantener prácticas de codificación seguras.
¿CSP detiene todos los ataques de secuencias de comandos entre sitios?
No. CSP es una defensa en profundidad. Una lista de permitidos débil, una ejecución en línea insegura, scripts confiables vulnerables o un manejo de datos inseguro aún pueden dejar rutas explotables. Prevenir la inyección sigue siendo el primer control.
¿Puede un juego de navegador guardar secretos en JavaScript o WebAssembly?
No. El código y los datos entregados a un navegador controlado por el jugador deben tratarse como inspeccionables y modificables. Los secretos de larga duración y las decisiones de apuestas autorizadas pertenecen a sistemas de servidores confiables.
¿Cómo se deben controlar los scripts de juegos de terceros?
Minimícelos, fije las versiones aprobadas, cárguelos desde orígenes explícitos, aplique metadatos de integridad donde corresponda, aíslelos cuando sea práctico y revise cada capacidad que reciban. Un administrador de etiquetas no debería convertirse en una ruta de ejecución sin restricciones.
