Server-Side Firewall for Anti-Exploit RemoteEvents
ESCOPO
This prompt creates a centralized security system for RemoteEvents, designed to prevent malicious clients from sending invalid payloads, spamming invocations, forging instance references, or trying to execute actions without the requirements enforced by the server.
The result is a ready-to-use Luau Script for ServerScriptService, with configuration per RemoteEvent, strict validation of types and values, player-based rate limiting, cooldowns, audit logs for suspicious attempts, and secure integration with legitimate game handlers. It is ideal for developers who have combat, inventory, economy, trades, quests, or any client-triggered mechanic.
The prompt also requires the AI to adapt the solution to the real project hierarchy. Just paste the object names in the Explorer, the existing RemoteEvents, and the business rules that need to be protected to receive a contextualized implementation ready to test in Roblox Studio.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, multiplayer architecture, and server-side anti-exploit security. Create a centralized, complete firewall to validate the existing RemoteEvents in my game, without trusting the client to authorize damage, currency, inventory, XP, teleport, purchases, or any important state change. Before writing the code, analyze the context I will provide below. If any essential information is missing, ask at most 5 objective questions. If I do not reply, assume safe defaults, clearly state the assumptions made, and produce a functional version that is easy to adapt. Do not invent RemoteEvents, folders, attributes, data systems, or APIs that do not exist in the context unless you explicitly mark them as configurable points. MY GAME CONTEXT (I will fill in): - Relevant Explorer structure: [PASTE HERE] - Location of the RemoteEvents/RemoteFunctions: [PASTE HERE] - List of remotes and the purpose of each one: [EX.: DealDamage(target, weaponId), BuyItem(itemId), EquipItem(itemId)] - Expected argument format for each remote: [PASTE HERE] - Existing server-side systems that should perform the real action: [PASTE HERE] - Business rules and permissions: [PASTE HERE] - Desired spam/cooldown and punishment limits: [PASTE HERE] - Desired log format: [warn, DataStore forbidden, existing external webhook, etc.] MANDATORY TYPE AND LOCATION: generate a single server Script, to be placed in ServerScriptService, with the suggested name "RemoteEventFirewall.server.lua". This Script must locate the existing RemoteEvents through configurable paths at the top of the file, connect OnServerEvent explicitly for each protected remote, and centralize the validation routines. Do not use a LocalScript for security validation. Do not put authoritative logic in ReplicatedStorage. If it is truly necessary to suggest a complementary ModuleScript for clean integration, treat it only as an optional alternative after delivering the fully functional single Script; do not make the operation dependent on that additional module. The code must be complete Luau, ready to paste, and come entirely inside a single markdown block ```lua. Include helpful comments in Portuguese, clear names, Luau typing when it improves maintainability, and a CONFIG section at the start of the Script. Do not deliver pseudocode, incomplete snippets, comments like "implement here" without a safe implementation, or client code. Implement a robust architecture with: declarative policy tables per RemoteEvent; secure path resolution; validation of the remote's existence and class; validation of count, type, nil, string, finite number (rejecting NaN and infinity), numeric limits, string length, excessively large tables, and table depth; whitelist for IDs/enums when applicable; and strict Instance validation. For any Instance received from the client, validate that it still exists, belongs to the DataModel, has the expected class, and is a permitted reference for that operation. Never accept from the client values such as final damage, final price, balance, rarity, granted quantity, item owner, or the result of a purchase. Implement rate limiting per player and per remote using a time window or token bucket, plus optional cooldown per action. The system must log rejected attempts with Player.UserId, player name, remote, sanitized reason, and infraction count. Include configuration for graduated actions: warn only, block the call, and kick after a configurable threshold. Do not perform automatic permanent bans, DataStore writes, or HTTP calls. Avoid exposing internal details to the client: when rejecting, simply block and log on the server. The business action must remain authoritative on the server. Demonstrate in the Script itself how each approved remote calls a specific server-side handler, where the server recalculates critical values. For combat examples, validate distance, attacker/target state, cooldown, team, and authorized tool/equipment before calculating damage on the server. For economy and inventory, validate balance and item ownership on the server and derive price, reward, and quantity from server-side tables. If my context does not include these systems, create clearly isolated and disabled-by-default safe example handlers, without pretending to integrate with systems that do not exist. Handle players leaving with memory cleanup for rate limits, cooldowns, and infractions. Protect callbacks with pcall/xpcall when it makes sense, preventing a malformed call from crashing the processing of the other remotes. Do not use loadstring, require of external assets, HttpService for remote execution, or any obfuscation technique. Do not claim that the system makes the game "impossible to exploit"; explain that it reduces the attack surface and that every critical rule must still live on the server. After the code block, provide: 1) a brief explanation of the per-remote configuration; 2) which parts I should adapt to the names and systems in my Explorer; 3) a list of tests in Roblox Studio using Start Server with 2 players, including invalid payloads, spam, improper Instance references, and forged purchase/damage attempts; and 4) limitations and recommendations to also review all RemoteFunctions and existing server-side scripts. Answer in Brazilian Portuguese.
