The Client-Server Model: Why It Exists
Roblox runs two environments: the server (one authoritative instance) and clients (one per connected player). The server owns the game state: data, physics authority for anchored objects, and game logic. Clients handle rendering, input, and local UI. Neither environment can directly access the other's variables or call the other's functions. RemoteEvents and RemoteFunctions are the only way to communicate between them. This separation exists because any client can be compromised. Roblox exploits inject code into the client environment, giving the exploiter full control over everything on their client: they can fire any RemoteEvent with any arguments, read any client-side variable, and modify any local instance. The only thing they cannot do is modify the server directly. This is why the server must never trust anything the client sends without validation.
RemoteEvent vs. RemoteFunction: When to Use Each
RemoteEvents are fire-and-forget: the sender sends data and continues executing without waiting for a response. Use them for the vast majority of communication: player actions (attack, interact, purchase), server broadcasting (update leaderboard, play effect for all players), and any case where the sender does not need a return value. RemoteFunctions are request-response: the caller sends a request and yields until the other side returns a value. Use them only when the client genuinely needs data from the server before it can proceed, such as fetching inventory data to display. Never use RemoteFunction where the server invokes a function on the client (ServerToClient), because the client can refuse to respond or delay indefinitely, hanging the server thread. This is a denial-of-service vulnerability. If the server needs to send data to the client, use a RemoteEvent and let the client handle it asynchronously.
- RemoteEvent:FireServer() — client tells the server something happened (use for 95% of cases)
- RemoteEvent:FireClient() — server tells a specific client to do something (play VFX, update UI)
- RemoteEvent:FireAllClients() — server broadcasts to all clients
- RemoteFunction:InvokeServer() — client requests data from server and waits for response
- Never use RemoteFunction:InvokeClient() — the client can hang the server
Server-Side Validation: The Non-Negotiable Step
Every OnServerEvent handler must validate every argument before acting on it. Treat every parameter as potentially malicious. Type-check everything: if you expect a number, verify typeof(arg) == "number". If you expect an Instance, verify it exists and is the correct class. Bounds-check values: if the client sends a damage number, ignore it entirely and calculate damage on the server based on the player's actual weapon and stats. If the client sends a target player, verify the target exists, is alive, and is within range using server-side position data, not client-reported positions. Verify the sender is allowed to perform the action: is the player alive? Are they in the correct game state? Do they own the item they are trying to use? Every check you skip is an exploit vector. A common pattern is a validation module that provides functions like ValidateType(value, expectedType), ValidateRange(value, min, max), and ValidateInstance(value, expectedClass) that you call at the top of every remote handler.
Rate Limiting: Preventing Remote Spam
Exploiters can fire RemoteEvents thousands of times per second. Without rate limiting, this can crash your server or trigger game logic far faster than intended (infinite damage, currency generation, etc.). Implement a simple rate limiter on the server: maintain a table of player -> timestamp tracking the last time each remote was processed. Before handling a remote call, check if enough time has passed since the last call. For combat actions, 0.1-0.2 seconds between calls is reasonable. For purchases, 0.5-1 second. If the rate limit is exceeded, drop the call silently. Do not send an error back to the client because that gives exploiters feedback. For a more robust solution, use a token bucket pattern: each player starts with a bucket of N tokens that refill at a fixed rate. Each remote call consumes one token. When the bucket is empty, calls are dropped until tokens refill. This handles bursts naturally while still capping sustained abuse.
Common Exploits and How to Prevent Them
The most exploited pattern in Roblox games is trusting client-reported values. If your DealDamage remote accepts a damage number from the client, an exploiter will send 999999 and one-shot everything. Calculate damage on the server. If your GiveItem remote accepts an item ID from the client, an exploiter will send any item ID in the game. Verify the item is a valid drop from the source the player is interacting with. If your TeleportPlayer remote moves the player to a client-specified position, exploiters will teleport anywhere. Validate that the target position is legal based on game state. Other common exploits: firing remotes for actions the player has not unlocked (sending ability fire events for abilities they do not own), firing remotes as another player (always use the first argument of OnServerEvent which is the verified player, never a player argument the client provides), and replaying old remote calls to duplicate rewards (track completed actions in a set and reject duplicates).
- Never trust client damage values — calculate on server from weapon stats
- Never trust client position data — use server-side positions for range checks
- Always use the first parameter of OnServerEvent as the player identity, not a client-sent argument
- Track completed one-time actions (quest rewards, boss kills) to prevent replay attacks
- Validate item ownership before allowing use or trade
Organizing Remotes at Scale
Small games can get away with a few RemoteEvents in ReplicatedStorage. Large games with dozens of systems need structure. Create a RemoteEvents folder in ReplicatedStorage and organize remotes by system: Combat, Inventory, UI, Social, etc. Name remotes clearly: CombatAttackRequest, InventoryMoveItem, UINotify. On the server, create a single handler module per system that connects to all its remotes and handles validation centrally. Alternatively, use a single RemoteEvent with an action identifier as the first argument and route to handler functions in a lookup table. This reduces the number of remote instances and centralizes your validation pipeline. Whichever approach you choose, document each remote's expected arguments and which server module handles it. When your game grows to 40+ remotes, documentation prevents the exact confusion that leads to security gaps.