Server-Authoritative Design: FiveM's Most Important Architectural Property

What the property actually means

For any given action, a server-authoritative handler doesn't derive its decision from data the client supplied for that decision — it looks up its own truth (config, database, session state) and treats the client's message as a request, not an instruction. The opposite is a client-trusting handler: one that takes a value the client sent and writes it to state as if the client were a reliable source.

This matters more than almost any other property because a client is hardware you don't control, running code the player can modify freely. Anything a client-trusting handler accepts, a modified client can send however the attacker likes.

How to spot a client-trusting handler

The following is a generic, illustrative contrast — not code from any specific product:

• Client-trusting: a net event handler that takes an item id and a price as arguments, then adds the price directly to the player's balance. The bug is the second argument — the price came from the client, and the handler simply wrote it down.
• Server-authoritative: a handler that takes only the item id, looks the price up in server-side config, and adds that looked-up value. The client's number never enters the calculation at all.
• The fifteen-second check: does any variable that reaches a database write, a balance change, or a permission decision trace back to an argument the client passed for that exact purpose? If yes, that's the tell.

Where this shows up beyond money

The same property governs permissions (never trust a client-sent job, role, or admin flag — check the server-side job table or ACL instead), ownership (never trust a client's claim that a vehicle or property is theirs — verify against the stored owner record), and state (never trust a client's claim to be on duty, in range, or in a particular mode without a server-side check). This guide covers the architectural property itself; the four concrete validations every net event needs — source, permission, rate, and argument types — are covered in full in our net-event security guide, which this one defers to rather than repeats.

A review checklist

• Every price, payout, and cost traces to server-side config or a database lookup — never a client-sent argument.
• Every ownership check queries the stored record — never trusts a client's claim about what belongs to them.
• Every permission check reads server-side job, role, or ACL state — never a client-sent flag.
• The client's role in any exchange is ask, wait, and render the server's answer — nothing more.
• Escrow and obfuscation don't substitute for this property — a genuinely authoritative server doesn't need to hide its client code to be safe, because the client was never trusted with anything that mattered in the first place.

Why this is the property, not a property

A performance problem gets worse slowly and predictably as your server grows. A non-authoritative handler gets worse the moment someone notices it, and the damage scales with exactly the things a successful server has more of: players, transactions, and time running. That asymmetry — a category of bug that punishes success — is why this sits ahead of feature count or UI polish in any serious evaluation of a script, and why it's worth checking before anything else you'd normally look at first.