Firewall Server-Side para RemoteEvents Anti-Exploit
ESCOPO
Este prompt cria um sistema de segurança centralizado para RemoteEvents, projetado para impedir que clientes maliciosos enviem payloads inválidos, spamem invocações, forjem referências de instâncias ou tentem executar ações sem os requisitos exigidos pelo servidor.
O resultado é um Script Luau pronto para ServerScriptService, com configuração por RemoteEvent, validação rigorosa de tipos e valores, rate limiting por jogador, cooldowns, auditoria de tentativas suspeitas e integração segura com handlers legítimos do jogo. Ideal para desenvolvedores que possuem sistemas de combate, inventário, economia, trades, missões ou qualquer mecânica acionada pelo cliente.
O prompt também exige que a IA adapte a solução à hierarquia real do projeto. Basta colar os nomes dos objetos no Explorer, os RemoteEvents existentes e as regras de negócio que precisam ser protegidas para receber uma implementação contextualizada e pronta para testar no Roblox Studio.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior especializado em Luau, arquitetura multiplayer e segurança anti-exploit server-side. Crie um firewall centralizado e completo para validar RemoteEvents existentes no meu jogo, sem confiar no cliente para autorizar dano, moedas, inventário, XP, teleporte, compras ou qualquer alteração de estado importante. Antes de escrever o código, analise o contexto que fornecerei abaixo. Se algum dado indispensável estiver ausente, faça no máximo 5 perguntas objetivas. Caso eu não responda, assuma padrões seguros, declare claramente as premissas adotadas e produza uma versão funcional e fácil de adaptar. Não invente RemoteEvents, pastas, atributos, sistemas de dados ou APIs que não existam no contexto sem marcá-los explicitamente como pontos configuráveis. CONTEXTO DO MEU JOGO (vou preencher): - Estrutura relevante do Explorer: [COLE AQUI] - Localização dos RemoteEvents/RemoteFunctions: [COLE AQUI] - Lista de remotes e finalidade de cada um: [EX.: DealDamage(alvo, armaId), BuyItem(itemId), EquipItem(itemId)] - Formato esperado dos argumentos por remote: [COLE AQUI] - Sistemas server-side já existentes que devem executar a ação real: [COLE AQUI] - Regras de negócio e permissões: [COLE AQUI] - Limites desejados de spam/cooldown e punição: [COLE AQUI] - Forma desejada de logs: [warn, DataStore proibido, webhook externo já existente etc.] TIPO E LOCALIZAÇÃO OBRIGATÓRIOS: gere um único Script de servidor, para ser colocado em ServerScriptService, com nome sugerido "RemoteEventFirewall.server.lua". Esse Script deve localizar os RemoteEvents já existentes por caminhos configuráveis no topo do arquivo, conectar OnServerEvent de forma explícita para cada remote protegido e centralizar as rotinas de validação. Não use LocalScript para validação de segurança. Não coloque lógica autoritativa em ReplicatedStorage. Se for realmente necessário sugerir um ModuleScript complementar para integração limpa, trate-o apenas como uma alternativa opcional após entregar o Script único totalmente funcional; não torne o funcionamento dependente desse módulo adicional. O código deve ser Luau completo, pronto para colar, e vir integralmente dentro de um único bloco markdown ```lua. Inclua comentários úteis em português, nomes claros, tipagem Luau quando isso melhorar a manutenção e uma seção CONFIG no início do Script. Não entregue pseudocódigo, trechos incompletos, comentários como "implemente aqui" sem uma implementação segura, nem código de cliente. Implemente uma arquitetura robusta com: tabela declarativa de políticas por RemoteEvent; resolução segura de caminhos; validação de existência e classe do remote; validação de quantidade, tipo, nil, string, número finito (rejeitando NaN e infinito), limites numéricos, tamanho de strings, tabelas excessivamente grandes e profundidade de tabelas; whitelist para IDs/enums quando aplicável; e validação rigorosa de Instance. Para qualquer Instance recebida do cliente, valide que ela ainda existe, pertence ao DataModel, possui a classe esperada e é uma referência permitida para aquela operação. Nunca aceite do cliente valores como dano final, preço final, saldo, raridade, quantidade concedida, dono de item ou resultado de uma compra. Implemente rate limit por jogador e por remote usando janela de tempo ou token bucket, além de cooldown opcional por ação. O sistema deve registrar tentativas rejeitadas com Player.UserId, nome do jogador, remote, motivo sanitizado e contagem de infrações. Inclua configuração para ações graduais: somente warn, bloquear chamada, e kick após um limiar configurável. Não faça banimentos permanentes automáticos, DataStore writes ou chamadas HTTP. Evite expor detalhes internos ao cliente: ao rejeitar, apenas bloqueie e registre no servidor. A ação de negócio deve permanecer autoritativa no servidor. Demonstre no próprio Script como cada remote aprovado chama um handler server-side específico, no qual o servidor recalcula valores críticos. Para exemplos de combate, valide distância, estado do atacante/alvo, cooldown, equipe e ferramenta/equipamento autorizado antes de calcular o dano no servidor. Para economia e inventário, valide saldo e propriedade do item no servidor e derive preço, recompensa e quantidade a partir de tabelas server-side. Caso meu contexto não inclua esses sistemas, crie handlers seguros de exemplo claramente isolados e desativados por padrão, sem fingir integração com sistemas inexistentes. Trate jogadores saindo com limpeza de memória de rate limits, cooldowns e infrações. Proteja callbacks com pcall/xpcall quando fizer sentido, evitando que uma chamada malformada derrube o processamento dos demais remotes. Não use loadstring, require de assets externos, HttpService para execução remota, nem qualquer técnica de obfuscação. Não alegue que o sistema torna o jogo "impossível de explorar"; explique que ele reduz a superfície de ataque e que toda regra crítica precisa continuar no servidor. Após o bloco de código, apresente: 1) uma explicação curta da configuração por remote; 2) quais trechos devo adaptar aos nomes e sistemas do meu Explorer; 3) uma lista de testes no Roblox Studio usando Start Server com 2 jogadores, incluindo payloads inválidos, spam, referências Instance indevidas e tentativas de compra/dano forjadas; e 4) limitações e recomendações para revisar também todos os RemoteFunctions e scripts server-side existentes. Responda em português do Brasil.
