Skip to content
Vice Drip
FiveM answers

What does server-authoritative mean in FiveM?

Server-authoritative means the FiveM server computes and decides everything that matters — prices, payouts, permissions, ownership, and the outcome of every action — while the client only requests and displays. The opposite, a client-trusting design, accepts values the client sends, such as an amount or a role flag, and writes them to state. Because any player can run a modified client and trigger any server event with any payload, only server-authoritative code is defensible.

In one lineServer-authoritative is the design property where the server independently verifies and decides every state change, never writing a client-supplied fact to state without checking it.

The longer answer.

The property is binary at every handler. Either the server worked out the fact itself — looked up the price from its own config, checked the player's job from its own records, computed the payout from its own timer — or it took the client's word for it. There is no partially authoritative event; a script can be authoritative in ninety-nine handlers and lose the economy through the hundredth.

It matters because the client is not yours. A player's game runs on their hardware, and tools that trigger arbitrary server events with arbitrary arguments are common. A handler that reads `amount` from a client event and adds it to a balance is not a bug waiting to be found; it is an ATM. The same applies to positions ("I am at the drop-off"), states ("I am on duty"), and identities ("I am the owner of this vehicle") — anything the client asserts must be re-derived on the server.

You can spot the opposite without reading escrowed code. Ask the seller how each money-moving or permission-changing event validates its source, permission, rate, and argument types; a seller who cannot describe that has not done it. On an open resource, search the server files for handlers that use a client-sent number directly. On staging, trigger the events yourself with wrong arguments and see whether the server refuses. That last test is the only one that does not depend on anyone's word.

The checklist.

  1. 01Every net event validates the source is a real, connected player.
  2. 02Permission is checked against server-side records, never a client flag.
  3. 03Amounts, prices, and payouts come from server config or server computation.
  4. 04Positions and distances are verified server-side before any location-based reward.
  5. 05Rate limits stop a valid event from being fired a thousand times.
  6. 06Argument types are checked before use — a string where a number was expected is rejected, not coerced.
Go deeper

Where this is covered in full.

Related questions

People asking this also ask.

Next

Where to go from here.

Published 2026-09-06 · Last reviewed 2026-09-06 · Vice Drip · All answers