Start Here · Think like a developer

The one rule: never trust the client

You are about to learn the single most important idea in FiveM scripting. Almost every exploit you will ever read about, free money, free items, instant admin, traces back to one mistake: a script that believed something the player's computer told it. Get this one rule into your head now and most of FiveM security stops feeling like a mystery. The rule is short. The client asks. The server decides.

You'll learn: Why almost every FiveM exploit comes from trusting the player's PC, and the one habit that stops them: the server decides, the client only asks.
Time: ~10 minutes
Difficulty: Beginner. No code to run, one idea to lock in.
You need: Nothing installed. Just the lesson before this one finished.

Watch

RED: never trust the client, shown in practice.

BEFORE YOU START

The one rule

When a player joins your server, your code runs in two places at once. Part of it runs on the server, the machine you control. Part of it runs on the client, the player's own computer. Those two halves talk to each other over the network.

Here is the catch. The client runs on the player's PC, and the player owns that PC completely. They can open the files, change the values, run a cheat program that rewrites your code while the game is running. So anything the client says is just a claim, not a fact. A cheater can make the client claim anything they want.

That is why one side has to be the boss. In FiveM, that side is the server. The server runs on your machine, where the player cannot reach it. So the server is the only place you can trust to make real decisions. We call this server authority: the server is the authority on what is true, and the client only sends requests.

Vocabulary

client: The copy of your code running on the player's own computer. The player controls it fully, so it can lie.
server: The copy of your code running on your machine. Players cannot touch it, so it is the only trusted side.
server authority: The principle that the server, not the client, decides anything that matters. The client only asks.
validation: The server checking a request before acting on it: is this allowed, do these numbers make sense, is this even possible.
exploit: A way for a player to break the rules by feeding the server input it should have refused.
source: A value FiveM stamps on every request so the server knows which connection sent it. The player cannot fake this, but it only proves who asked, not that the request is allowed.

Why it is true

It is easy to read "never trust the client" and nod without feeling why. So picture the player on the other end.

They are sitting at their own computer. Your client script is a file on their hard drive. They can open it in a text editor and read every line. They can change a number, save it, and reload. Worse, there are cheat menus, programs that inject new code into the running game, that let them send any message to your server at any moment, with any values attached.

So when a cheater wants free money, they do not "hack the server." They do something much simpler. They make their client send the server a message that says "give me a million dollars." If your server reads that number and adds it, the cheater wins, and they did not break anything. They just used your own code the way you wrote it.

The server is the one thing the cheater cannot edit. It is on your machine. That is the whole reason the server, and only the server, gets to decide. Everything else in FiveM security is just this idea applied to one feature at a time.

What "validate on the server" means

So the server cannot believe the client. What does it do instead? It validates. Validation means the server checks a request before acting on it. There are three checks you will reach for again and again.

Check the player is allowed

Before doing anything privileged, the server asks: is this player even allowed to do this? Can they open the police armory? Are they an admin? You check this on the server using data only the server holds, never because the client said "trust me, I'm a cop."

Check the values make sense

If the request includes numbers, the server checks they are sane. Is the amount inside the allowed range? Has enough time passed since the last time (a cooldown)? Is the player actually standing near the shop, or are they claiming to buy from across the map (a distance check)? Anything physically impossible is a sign of a cheat, and the server refuses it.

Never let the client send the final number

This is the big one. For anything valuable, money, item counts, prices, the client must never send the final figure. The client says what it wants. The server looks up the real number from its own data and uses that.

Here is the difference in the smallest possible form.

lua

-- BAD: the server adds whatever number the client sent
RegisterNetEvent('shop:buy', function(amount)
    local src = source
    giveMoney(src, amount) -- a cheater sends amount = 1000000 and gets it
end)
 
-- GOOD: the server looks up the real value itself
RegisterNetEvent('shop:buy', function(itemId)
    local src = source
    local price = PRICES[itemId] -- the server's own data decides the number
    chargeMoney(src, price)
end)

In the bad version, the client's number flows straight into the action. In the good version, the client only names what it wants, itemId, and the server decides the price from its own table. There is no number on the wire for a cheater to inflate, because the number never left the server.

A mental checklist

You do not need to memorize a long list. You need one question you ask yourself before writing any feature.

Common beginner mistakes

These three show up constantly in beginner code and in leaked scripts. Each one is the same mistake wearing a different hat: the server trusted the client.

Symptom	Fix
`TriggerServerEvent('giveMoney', amount) where the server adds whatever amount the client sent`	The client picked the amount, so a cheater picks a million. The server must derive the amount from its own data (a reward table, a price list, a database row), never from a value the client passed.
`Checking permission on the client only (hiding a button so it 'feels' admin-only)`	Hiding the button is just UX. A cheater never sees your button anyway, they fire the event directly. The real permission check must happen on the server before the action runs.
`Trusting client-sent coordinates for a teleport`	If the client says 'put me here,' a cheater says 'put me inside the bank vault.' The server must check the destination is a known, allowed location and a reachable distance before it moves anyone.

A client event sends amount = 1000000. Why must the server not just add it?

Because the player owns the machine that sent that number, so the number is a claim, not a fact. A cheater can set amount to anything by editing their client or using a cheat menu. If the server adds whatever arrives, the player has a money printer. The fix is server authority: the server ignores the client's number and works out the real amount from its own data, a reward constant, a price table, a database value. The client gets to ask. It never gets to decide the figure that matters.

Try it yourself

TRY IT YOURSELF

No server needed. Read this server handler, find the flaw, and describe the fix in one sentence.

lua

RegisterNetEvent('bank:deposit', function(amount)
    local src = source
    addBankBalance(src, amount) -- trusts the client's number
end)

Where is the trust mistake, and how would you fix it?

Solution: the flaw is that the server adds amount straight from the client, so a cheater sends any number they like and inflates their balance. The fix is to never let the client send the final figure. The server should determine the amount itself, for a deposit that means reading how much cash the player actually has from the server's own records and depositing that, not trusting a number the client supplied. The client may say "I want to deposit," but the server decides how much is real.

You go deeper in Track B

What you just learned is the principle. Track B is where you build the defenses on top of it, hands on. There you will write the actual checks: validating every value that arrives in an event (its type, its range, whether it is even a real number), rate limits that reject a player spamming an event hundreds of times a second, and integrity patterns that catch impossible game states. Every one of those techniques is the same rule you learned here, applied with code. You now hold the idea they all rest on. The client asks, the server decides.

What you can do now

Say the rule out loud: the client asks, the server decides.
Explain why the client can lie: the player owns the PC it runs on, so anything it sends is a claim, not a fact.
Spot the trust mistake in code where a server adds, grants, or moves based on a number the client sent.
Know the three server checks: is the player allowed, do the values make sense, and never let the client send the final number.
Use the one question before any feature: if it changes money, items, or permissions, the server decides.

You have the rule that holds the rest of FiveM security together. Next, in "Performance and project structure," you will learn how to keep a server with all these checks running fast and organized, so safety never costs you smooth gameplay.

REFERENCES

FiveM docs: server-side security ↗