How to protect your FiveM server from cheaters: a practical security guide

Cheaters on a FiveM server rarely beat one big wall. They walk through a dozen small doors that were left open: a server event that trusts the client, an admin permission tied to the wrong identifier, a leaked script with a backdoor, a convar nobody set. This guide closes those doors in the order that gives you the most protection for the least work.

It is written for server owners and developers running ESX, QBCore, vRP, NDCore or a standalone server. Nothing here needs a paid product. An anticheat comes last, on purpose: it works best on a server that is already hard to abuse.

1. Start with server.cfg

A few lines in server.cfg decide what a modified game client may do at all. Check that these are set the way you intend:

# OneSync: the server tracks entities and players, which most
# server-side checks depend on.
set onesync on

# No ScriptHookV-based mods on your server.
sv_scriptHookAllowed 0

# Pure mode: 1 allows only modified audio and graphics files,
# 2 blocks all modified game files.
sv_pureLevel 1

# Hide player IP addresses from the public server info.
sv_endpointPrivacy true

Two more settings are worth reading about on the Cfx.re documentation before you turn them on, because they change how your resources are allowed to behave:

• sv_entityLockdown limits which entities clients may create. relaxed blocks entities created by client scripts, strict blocks every client-created entity, so all spawning has to go through the server. Many older resources still spawn vehicles and props on the client, so test this on a copy of your server first.
• sv_filterRequestControl limits when a client may take network control of an entity another player owns, for example a vehicle someone else is driving. It makes it harder to delete or move vehicles other players are using.

Keep your FXServer artifacts current. Cfx.re ships security fixes in server builds, and an artifact that is a year old misses all of them. txAdmin shows you when a newer recommended build exists.

2. Lock down admin access

Most "hacked server" stories are not cheats at all. They are someone getting admin rights.

• Grant admin permissions with ACE to a stable identifier, never to an IP address or a player name:

  cfgCopy

  add_principal identifier.fivem:1234567 group.admin
  add_principal identifier.discord:123456789012345678 group.admin

• Give each staff member only the commands they need. A moderator rarely needs command or resource control.

• Leave rcon_password unset unless you really use RCON. Manage the server through txAdmin instead, and have every admin log in with a Cfx.re account that has two-factor authentication turned on.

• Remove former staff the day they leave: ACE lines, txAdmin accounts, Discord roles, database panel access and FTP/SFTP keys.

3. Treat every net event as hostile input

This is where most real-world damage happens. Any client can trigger any server event a resource registers with RegisterNetEvent, with any arguments it likes. A cheat menu does not need to "hack" anything to call a shop:buy event with a price of 0 or bank:deposit with a negative amount.

The rule is simple: the server decides, the client only asks.

-- Bad: the client sends the price and the amount.
RegisterNetEvent('shop:buy', function(item, price, amount)
  local xPlayer = ESX.GetPlayerFromId(source)
  xPlayer.removeMoney(price * amount)
  xPlayer.addInventoryItem(item, amount)
end)

-- Better: the server owns the price list and checks everything.
local PRICES = { bread = 5, water = 3 }

RegisterNetEvent('shop:buy', function(item, amount)
  local src = source
  local xPlayer = ESX.GetPlayerFromId(src)
  local price = PRICES[item]
  amount = math.floor(tonumber(amount) or 0)

  if not xPlayer or not price then return end
  if amount < 1 or amount > 20 then return end
  if not isNearShop(src) then return end          -- check the player's position on the server
  if xPlayer.getMoney() < price * amount then return end

  xPlayer.removeMoney(price * amount)
  xPlayer.addInventoryItem(item, amount)
end)

For every event that changes money, items, jobs, vehicles or another player, check on the server:

1. Who is calling: use source, never a player id sent as an argument.
2. What they send: types, ranges and whitelists. Reject anything you did not expect.
3. Where they are: compare the player's server-side position with the shop, job location or target.
4. Whether they may: job, grade, cooldown, ownership of the vehicle or item.
5. How often: a simple per-player cooldown stops event spam that tries to dupe items.

Do the same for callbacks (lib.callback, ESX.RegisterServerCallback, QBCore.Functions.CreateCallback) and for state bags a client is able to write. Our net event security guide goes deeper, with patterns you can copy.

4. Audit the resources you run

Leaked and "free premium" scripts are the most common way a backdoor gets onto a FiveM server. A backdoor usually downloads code from the internet and runs it, which gives a stranger full control of your server and database.

• Only install resources from their authors, the Cfx.re forum, Tebex stores you trust or a git repository you can read.
• Be suspicious of obfuscated server code from unknown sources, and of any resource that runs code it downloads with PerformHttpRequest.
• Remove resources you no longer use. Every resource adds events a client can call.
• Keep your framework and its core resources (inventory, banking, phone) up to date. Exploits in popular resources are published and used quickly.

5. Separate secrets from the game server

• Database passwords, webhook URLs and API keys belong in convars set in a private server.cfg (or environment variables), not in files that end up in a public repository.
• Discord webhooks that sit in client files are readable by every player. Send webhooks from the server only.
• Back up the database automatically and keep at least one copy off the machine.

6. Use txAdmin for what it is good at

txAdmin ships with FXServer and handles day-to-day administration: restarts, the live console, player history, warnings, bans and whitelisting. Set it up properly:

• Have admins log in with Cfx.re accounts that use two-factor authentication.
• Use a whitelist mode if your community allows it (Discord role, approved licence or admin-only during development).
• Schedule restarts so memory leaks in resources don't build up.

txAdmin manages your server; it does not detect cheats. txAdmin and an anticheat explains how the two divide the work.

7. Add an anticheat for what the server cannot see

Steps 1 to 6 stop most abuse that goes through your scripts. They cannot stop a modified client from doing things the game itself allows: aiming for the player, moving faster than possible, spawning things, seeing through walls or injecting its own code. That is the job of an anticheat.

What to look for is covered in How to choose a FiveM anticheat. In short: evidence on every ban, a way to deal with false positives before they ban innocent players, protection against banned players returning on a new account, and support for your framework.

Parity is the anticheat we build for this. It runs as one resource next to your framework, attaches screenshots and video clips to bans as evidence, links returning accounts to their old ban, and lets you choose log, kick or ban per detection, so a new check can start on log until you trust it. You can try the full dashboard in the demo without an account.

Checklist

• OneSync on, ScriptHook off, pure mode set, endpoint privacy on
• Entity lockdown and request-control filtering tested on a copy of the server
• Current recommended FXServer artifact
• Admin rights via ACE on stable identifiers, 2FA on staff accounts, RCON off
• Every money, item, job and vehicle event validated on the server
• Resources from trusted sources only, unused ones removed
• Secrets in private config, webhooks server-side only, automatic backups
• An anticheat with evidence and false-positive handling