Data security — never trust the player

Here's the uncomfortable truth of online games: your players are not all trustworthy.

Some players modify the game running on their own computer. A few do it by hand, but the ones that matter do it automatically. These players are called exploiters, and building so they can't break anything is what this lesson is about.

#The bad version: client gives client coins

Remember the two computers from the scripts lesson? A LocalScript runs on the player's machine. So this:

-- LocalScript (runs on the PLAYER's computer)
game.Players.LocalPlayer.leaderstats.Coins.Value = 999999

…runs on the player's own computer. And here's the horror: if the leaderstats folder is replicated to clients, that line can actually change what the leaderboard shows.

A player who wants free coins just runs one line of code. Congratulations — your economy is broken.

#The good version: server decides, client asks

The rule, in one sentence:

The server is the only thing that can change real data. Clients can only request.

So coins work like this:

1. The client clicks the coin. That's a request.
2. The server decides: did they really click? Is it a fair request? If so — and only so — the server gives coins.
3. The leaderboard shows whatever the server set.

If an exploiter sends a million fake clicks, the server checks each one and says "no" — because the server doesn't care what the client's screen claims. The client can claim anything; the server awards what it verifies.

#The first security habit: verify

A server callback that rewards coins should always verify before it awards:

function onCoinClicked(player)
    if player ~= nil and player:IsDescendantOf(game.Players) then
        local coins = player.leaderstats.Coins
        coins.Value = coins.Value + 10
    end
end

The if checks the player is real before touching their data. That's the mindset: assume the worst, verify the minimum.

-- guard the purchase

#Three rules to live by

1. Never let a client set its own money. Real data changes only on the server.
2. Clients request; servers decide. Clicks, buys, and claims are requests to the server, not commands.
3. Verify before you award. Who is this player? Did this action actually happen?

#Common mistakes

• Giving rewards in a LocalScript. Every "earn" must be server-side. If the code that changes data can run on the player's machine, so can the exploit.
• Thinking 'my players are nice.' Assume all clients are hostile, and your good players never notice a difference.
• Hiding code to protect it. Exploiters don't need to read your code — they run their own on their machine. Protection is about authority (server decides), not secrecy.

Next: the plumbing that lets the client ask the server — RemoteEvents.