FiveM Anticheat: What Actually Works and What Is Snake Oil

It controls whether clients are allowed to create entities — vehicles, objects, peds. The documented modes:

• inactive — clients can create any entity they want. This is the default.
• relaxed — only script-owned entities created by clients are blocked.
• strict — no entities can be created by clients at all.

Sit with that default for a second. Out of the box, a client can ask the server to create whatever it likes. That is the mechanism behind a large share of "someone spawned a hundred tanks on my server" incidents. It is not an exotic exploit; it is the documented default behaviour.

set sv_entityLockdown "strict"

Strict is the goal for a roleplay server, because on an RP server the server should own the world — vehicles come from a garage script, objects come from a job script, and none of it should originate on a player's machine. Be warned that going straight to strict on a mature server will break resources that were quietly relying on client-side spawning, which is exactly why so many owners set it to inactive and move on. Do it on a test server, find what breaks, and fix those resources — they are the same resources an attacker would abuse.

If strict genuinely breaks too much, relaxed is a meaningful improvement over the default. Do not stop at inactive.

sv_stateBagStrictMode

State bags are how entity state is shared around, and by default clients can modify the state of networked entities. Turning this on means only the server can:

setr sv_stateBagStrictMode true

This closes off a whole family of state-manipulation exploits. It needs a reasonably recent server build, which you should be running anyway.

sv_scriptHookAllowed

Defaults to false, which is correct. Leave it. Cfx's own example config is refreshingly honest about the limits, noting that disabling scripthook does not guarantee players cannot use external plugins. It raises the floor; it is not a wall.

sv_pureLevel

Blocks modified client files. There are exactly two levels — you will see guides refer to a level 3; it does not exist.

• 1 — blocks all modified client files except audio files and known graphics mods.
• 2 — blocks all modified client files.

set sv_pureLevel 1

Level 1 is the sensible setting for most servers. Level 2 will lock out players running perfectly innocent graphics mods and will generate support tickets. Understand what this does and does not do: it is about file integrity, not about an external cheat menu injecting into the game. It is worth having; it is not an anticheat.

The networked-feature switches

Cfx documents several convars that are, in its own words, commonly used by malicious actors:

set sv_enableNetworkedPhoneExplosions false
set sv_enableNetworkedSounds false
set sv_enableNetworkedScriptEntityStates false

Phone explosions already default to false — leave them there. The other two default to true, so turning them off is an active decision. Test them: if nothing on your server breaks, that is free security. If something does break, you have learned something useful about a resource.

There is also sv_filterRequestControl, which blocks clients requesting control of entities they should not have — a common route to stealing occupied vehicles — and block_net_game_event, which blocks specific network game events outright.

The thing that is actually exploiting you

Now the part that matters more than every convar above combined.

The most common way a FiveM roleplay server gets exploited is its own scripts. Specifically: a server-side event that trusts what the client sends it.

If a client can fire an event that gives them money, spawns an item, sets their job, or completes a task — and the server does not independently verify that the request is legitimate — then a player does not need a cheat menu. They need the developer console and five minutes. Cfx's official security guidance is entirely about this, and it comes down to three habits:

• Use RegisterNetEvent only for events that genuinely must cross from client to server. Everything else should be a plain AddEventHandler, which a client cannot trigger.
• Never trust event arguments. If the client tells you how much money to add, you have already lost. The client says "I sold a fish"; the server decides whether the player has a fish, whether they are at the fish shop, and what a fish is worth.
• Validate everything server-side — money, inventory, position, permissions. The official recommendation is explicit that OneSync exists precisely so owners can build server-authoritative code.

This is unglamorous, it cannot be bought, and it is where essentially all of the real damage on roleplay servers comes from. A server with a clean event surface and default anticheat is dramatically safer than a server with a paid anticheat and a script that lets the client set its own bank balance.

Which brings us to the market.

The snake oil

Third-party anticheats are explicitly allowed by Cfx.re — its own FAQ says so plainly, and some of them are written by competent people. But be sceptical, and be sceptical for reasons Cfx itself has documented:

• "Protection rackets." Cfx.re calls this out by name: cheat authors pressuring server owners into buying their anticheat. If the same ecosystem that sells the exploit sells the cure, you are not a customer, you are a mark.
• Global ban lists. Cfx warns about these directly, on the grounds that the quality of any given anticheat's detections cannot be verified — and a global ban list can ban players without good reason. Handing a third party the power to permanently ban your community members based on detections you cannot audit is a bigger risk than most owners think it is.
• Detection-based promises. Any product claiming to detect "all menus" is selling you an arms race it does not win. Detection is inherently reactive; the cheat updates, the detection breaks.

None of that means every paid anticheat is worthless. It means it should be the last thing you buy, not the first — and it should never be the reason you skipped the free controls above.

What to actually do, tonight

1. Set sv_entityLockdown to strict on a test server and find out what breaks. Fix those resources. This is the highest-value hour you will spend on server security.
2. Turn on sv_stateBagStrictMode.
3. Set sv_pureLevel 1. Leave sv_scriptHookAllowed at false.
4. Turn off the networked-feature convars and see whether anything actually breaks.
5. Audit your RegisterNetEvent handlers. Every one of them. Ask of each: what happens if a player calls this directly with whatever arguments they like? If the answer is bad, that is your vulnerability — not a menu.
6. Keep your artifact current. Client-side detections ship in updates, and an artifact more than three months out of support is not even joinable from the server browser.
7. Only then consider a third-party anticheat, with your eyes open.

The uncomfortable summary: most FiveM "hacking" is not hacking. It is a server that asked the client what it wanted and believed the answer. You can browse resources and see their community reviews on the FiveM scripts marketplace — and when you install one, read its server events before you trust it with your economy.

Researched and drafted with AI assistance. How ViceHub guides are made