Limites de segurança de jogos de navegador: CSP, SRI e Trusted Types

Um jogo de navegador seguro começa com um limite claro: tudo o que é entregue ao jogador é inspecionável e potencialmente modificável, enquanto contas, apostas e resultados oficiais permanecem em sistemas de servidores confiáveis. Os controles do navegador, como Política de segurança de conteúdo, Integridade de sub-recursos e Trusted Types, reduzem caminhos específicos de ataque do lado do cliente dentro desse modelo maior.

Esses controles se complementam. CSP restringe o que o documento pode carregar ou executar. SRI verifica se os recursos externos selecionados correspondem a um resumo criptográfico esperado. Trusted Types pode restringir coletores de injeção DOM perigosos a valores produzidos por políticas aprovadas. Nenhum transforma o código do cliente em segredo e nenhum compensa uma decisão oficial deixada no navegador.

Mapeie primeiro cada executável e origem de rede

Uma política deve começar com um inventário do que o jogo realmente carrega: seu documento, scripts, trabalhadores, módulos WebAssembly, texturas, fontes, áudio, conexões API, telemetria e quadros incorporados. Registre o proprietário e a finalidade de cada origem. Uma dependência desconhecida não pode receber permissão deliberada.

Reduza a lista antes de codificá-la em CSP. Hospede automaticamente ativos estáveis quando apropriado, remova rastreadores não utilizados e mantenha os endpoints de desenvolvimento fora da configuração de produção. Curingas amplos tornam uma política mais fácil de implementar, mas mais fraca como limite de aplicação.

Trate o código de terceiros como código, mesmo quando ele chega por meio de análises ou de um gerenciador de tags. Um script confiável pode manipular o documento dentro dos recursos que a página oferece. Se uma dependência precisar apenas de dados de eventos, prefira uma integração estreita no lado do servidor ou um quadro isolado em vez da execução irrestrita do documento principal quando a arquitetura do produto permitir.

Construa CSP em torno de nonces ou hashes

Guia CSP de MDN explica como o cabeçalho de resposta pode restringir tipos de recursos e execução de scripts. Uma política estrita moderna normalmente autoriza os scripts de aplicativos pretendidos com nonces por resposta ou hashes em tempo de construção, em vez de manter uma longa lista de hosts.

Inicie no modo Content-Security-Policy-Report-Only, colete violações, remova dependências inesperadas e aplique a política. A denúncia é uma ajuda à migração e não uma razão para deixar a fiscalização desativada. Filtre dados confidenciais de relatórios e espere ruídos de extensões de navegador ou software local injetado.

Evite unsafe-inline e unsafe-eval, a menos que uma restrição de compatibilidade medida e documentada os exija. Alguns motores de jogo ou pacotes herdados compilam código dinamicamente; esse comportamento deve ser identificado durante a auditoria de construção, e não descoberto quando a fiscalização chega à produção.

Separe as diretivas por capacidade. script-src, connect-src, img-src, font-src, worker-src e frame-src respondem a perguntas diferentes. Um jogo que abre conexões WebSocket ou cria trabalhadores precisa desses endpoints declarados sem conceder a mesma permissão de origem aos scripts.

Use SRI para recursos externos imutáveis

Integridade de sub-recursos permite que um script ou link de folha de estilo declare um ou mais resumos criptográficos. O navegador faz hash do recurso buscado e recusa uma resposta que não corresponda. Isto é útil quando se espera que um ativo hospedado externamente seja imutável.

SRI não é gerenciamento automático de dependências. Cada alteração de recurso aprovada requer metadados de integridade correspondentes, e as buscas SRI de origem cruzada também dependem do servidor remoto que permite a solicitação por meio de CORS. Se um fornecedor fornecer alterações de conteúdo de um URL, fixar um resumo quebrará corretamente esse comportamento; a integração deve migrar para um artefato versionado ou um modelo de confiança diferente.

Gere valores de integridade do artefato de lançamento, não de uma cópia do desenvolvedor, e teste a resposta implementada. A transformação de conteúdo por um proxy ou CDN altera os bytes e deve causar falha na verificação. Retenha o artefato e seu resumo nas evidências de lançamento para que um incidente possa conectar a página à dependência exata esperada.

Use Trusted Types para reduzir os caminhos de injeção DOM

Trusted Types tem como destino APIs DOM que podem interpretar strings como HTML ou script. Quando a imposição está habilitada, os coletores protegidos aceitam valores digitados criados por políticas registradas em vez de cadeias de caracteres arbitrárias. Isso transforma decisões de injeção dispersas em um conjunto menor de transformações revisáveis.

O Documento W3C Trusted Types é um rascunho de trabalho, não uma recomendação final. O suporte do navegador deve ser verificado para a matriz do dispositivo do produto, e a construção segura do DOM continua necessária. A migração correta é remover primeiro a construção desnecessária da string HTML e, em seguida, colocar a higienização ou modelos estritamente revisados por trás das políticas nomeadas.

Não crie uma política padrão que retorne cegamente todas as entradas. Isso satisfaz um formato de API enquanto preserva a vulnerabilidade. Cada política deve ter um propósito, proveniência de entrada clara e testes com cargas maliciosas.

Mantenha a autoridade e os segredos do jogo no servidor

CSP, SRI e Trusted Types protegem a execução de documentos; eles não tornam o saldo, o resultado RNG, a titularidade ou a chave de assinatura confiáveis quando armazenados no cliente. JavaScript e WebAssembly são executados em um ambiente controlado pelo player.

O cliente pode renderizar um resultado e rejeitar entradas obviamente malformadas para fins de usabilidade, mas o servidor deve autenticar a sessão, validar as ações permitidas e possuir o estado autoritativo. Use credenciais de escopo curto e de curta duração e cookies ou tokens seguros padrão apropriados à arquitetura. Nunca envie uma chave privada reutilizável, uma credencial de banco de dados ou um token de serviço privilegiado em um pacote.

Este mesmo limite informa WebAssembly uso em jogos de cassino: a compilação altera a representação, não a confiança. Ele também pertence ao estágio de design do desenvolvimento de jogos de cassino, antes que as integrações de terceiros acumulem privilégios implícitos.

Transforme as violações da política em uma porta de liberação

Automatize verificações de cabeçalhos de produção, comportamento de nonce ou hash, falhas de SRI e execução inline proibida. Exercite o login, o carregamento do jogo, os trabalhadores, as chamadas de API e os caminhos de erro sob a política aplicada. Uma página inicial que passa enquanto o jogo perde silenciosamente seu trabalhador não é uma implantação bem-sucedida.

Mantenha um pequeno conjunto de testes negativos intencionais. Modifique um recurso fixado e confirme se SRI o bloqueia. Tente uma conexão não aprovada e confirme os relatórios CSP e evite-a. Passe uma string não confiável para um coletor protegido e confirme que a aplicação a rejeita. Um portão de segurança que nunca demonstrou falha ainda não é evidência.

Revise o inventário de origem com cada novo fornecedor, atualização de mecanismo e host de ativos. As políticas decaem quando as equipes adicionam exceções sem remover as obsoletas. A política mais segura é a mais restrita que suporta o comportamento de produção verificado.

Perguntas frequentes

O que a Política de Segurança de Conteúdo faz para um jogo de navegador?

A Política de Segurança de Conteúdo informa ao navegador quais fontes e padrões de execução uma página pode usar. Uma política rigorosa pode reduzir os caminhos pelos quais o conteúdo injetado se torna executável, mas não substitui a codificação de saída ou o design seguro do aplicativo.

O que é integridade de sub-recursos?

A integridade de sub-recursos permite que uma página forneça um hash criptográfico para um script ou folha de estilo buscado. O navegador compara a resposta com esse hash e se recusa a usar um recurso incompatível.

O que são Trusted Types?

Trusted Types é uma API de navegador para restringir coletores de injeção DOM perigosos a valores criados por políticas aprovadas. O documento W3C ainda é um rascunho de trabalho, portanto as equipes devem verificar o suporte do navegador e manter práticas de codificação seguras.

O CSP interrompe todos os ataques de script entre sites?

Não. CSP é uma defesa em profundidade. Uma lista de permissões fraca, execução em linha insegura, scripts confiáveis vulneráveis ou manipulação de dados insegura ainda podem deixar caminhos exploráveis. Prevenir a injeção continua sendo o primeiro controle.

Um jogo de navegador pode manter segredos em JavaScript ou WebAssembly?

Não. O código e os dados entregues a um navegador controlado pelo jogador devem ser tratados como inspecionáveis e modificáveis. Segredos de longa duração e decisões de apostas confiáveis pertencem a sistemas de servidores confiáveis.

Como os scripts de jogos de terceiros devem ser controlados?

Minimize-os, fixe versões aprovadas, carregue-as de origens explícitas, aplique metadados de integridade onde couberem, isole-os quando for prático e revise todos os recursos que receberem. Um gerenciador de tags não deve se tornar um caminho de execução irrestrito.