Locking down your server without breaking everything: entity lockdown, request control and server-side checks

Every week someone on the forum asks which anticheat is best. It’s a good question, but usually the second one. The first question is: what can a cheater do on your server that no anticheat can stop? The answer: anything your scripts and your config allow.

1. Limit what clients can create

sv_entityLockdown controls whether clients can create networked entities themselves:

• inactive: clients can create anything (the unsafe default);
• relaxed: entities created by client-side scripts are blocked;
• strict: clients can’t create any entities at all. Everything goes through the server.

You can set a different mode per routing bucket. According to the docs on what changes in FiveM for GTA V Enhanced, a mode is added there that also disables dummy objects. sv_protectServerEntities is not implemented on Enhanced, so use sv_entityLockdown there.

Relaxed isn’t watertight either. In a forum topic about cheaters creating entities as poptype 5, owners describe cheaters spawning vehicles and peds disguised as "population" entities, which relaxed mode doesn’t stop.

2. Filter "request control"

Cheats love taking control of someone else’s vehicle or entity. sv_filterRequestControl sets how strictly the server filters those requests. The higher the value, the stricter. The highest setting stops forwarding control requests altogether. Again, a high setting can break scripts that rely on it. Check the server commands documentation for what each value means exactly.

3. A starting point for your server.cfg

server.cfg# Clients can't create script entities
sv_entityLockdown relaxed

# Stricter filtering of entity takeovers
sv_filterRequestControl 2

# No networked sounds (stops siren spam)
sv_enableNetworkedSounds false

# Block modified client files.
# Note: this also blocks players' graphics and sound packs.
sv_pureLevel 1

Always test this on a dev server first. In the popular forum guide "How to protect your server from MOST cheaters", one reply rightly warns that many owners add settings like these without understanding what they break.

4. Never trust the client

This is the most important rule, and the reason so many servers still have money and item exploits despite an expensive anticheat. A cheater can trigger any event your client scripts can trigger, with any value they like.

lua-- ❌ The client decides how much money it gets
RegisterNetEvent('job:reward', function(amount)
  local xPlayer = ESX.GetPlayerFromId(source)
  xPlayer.addMoney(amount)
end)

-- ✅ The server decides and checks
local REWARD, MAX_DIST, COOLDOWN = 250, 5.0, 60
local JOB_POS = vec3(-1037.5, -2737.6, 20.2)
local lastDone = {}

RegisterNetEvent('job:complete', function()
  local src = source
  local coords = GetEntityCoords(GetPlayerPed(src))
  if #(coords - JOB_POS) > MAX_DIST then return end
  if lastDone[src] and os.time() - lastDone[src] < COOLDOWN then return end
  lastDone[src] = os.time()
  ESX.GetPlayerFromId(src).addMoney(REWARD)
end)

The difference: in the second example the client can only say "I’m done". The server checks whether that’s true (position and cooldown) and decides the amount itself. Do the same for items, vehicles and permissions.

5. Encryption isn’t security

The same forum topic sparked a discussion about encrypting client scripts. The conclusion from several experienced developers: client code can always be read in the end. Encryption at most slows down beginner script kiddies for a while and costs performance. Your time is better spent on server-side validation.

Checklist

1. Set sv_entityLockdown to at least relaxed and fix what breaks.
2. Configure sv_filterRequestControl and test your vehicle scripts.
3. Go through all your RegisterNetEvent handlers: which ones trust a value from the client?
4. Log economy and admin actions so you can trace exploits afterwards.
5. Don’t run leaked or "nulled" scripts: they regularly contain backdoors.
6. Only then pick an anticheat.