FiveM anticheat basics: what to do and what no anticheat can do

Cheaters are part of running a public server. They spawn vehicles, blow up the map, give themselves money and weapons, and drive away your honest players. A single "anticheat" resource will not fix that. What works is a few layers, starting with the most important one: do not trust the client.

#Layer 1: validate on the server

Most cheats on a roleplay server are not engine hacks. They are someone triggering your own events with values they chose. Fix that first, and a large part of the problem disappears.

• Compute prices, rewards and amounts on the server.
• Use source, never a player id sent by the client.
• Check job, distance and cooldowns before acting.

The full method with code is in securing server events. If you do only one thing from this article, do that.

#Layer 2: entity control with OneSync

With OneSync, the server knows about entities (vehicles, peds, objects) and can control who creates them. That lets you stop cheaters from spawning things.

• Entity lockdown. OneSync has an entity lockdown mode where client-created entities are blocked or restricted. It is strong, but it breaks any script that spawns vehicles or objects from the client. Read the OneSync documentation for the exact setting in your build before turning it on, and move spawning to the server first. See spawning vehicles server-side.
• entityCreating event. The server can inspect entities as they are created and cancel the ones you do not want.

AddEventHandler('entityCreating', function(entity)
    local model = GetEntityModel(entity)
    if model == `jet` then
        CancelEvent()
    end
end)

This example refuses to create a jet from anywhere. Build your own list of models that nobody on your server should create, and be careful: a rule that is too wide cancels your own scripts' entities.

OneSync must be enabled for these features. See OneSync and player limits.

#Layer 3: handle game events

FiveM sends some game actions to the server as events, and the server can cancel them. Two common ones:

#Explosions

AddEventHandler('explosionEvent', function(sender, ev)
    -- sender is the player who caused the explosion
    -- ev holds the explosion type and position
    CancelEvent()
end)

Cancelling every explosion would stop grenades and your own scripted explosions as well. Narrow it with the data in ev. For example, look at ev.explosionType and only cancel the types that should never happen on your server, or log them first to see what normal play produces.

local blocked = { [1] = true }  -- example: replace with the types you decide to block

AddEventHandler('explosionEvent', function(sender, ev)
    if blocked[ev.explosionType] then
        CancelEvent()
        print(('Blocked explosion from player %s'):format(sender))
    end
end)

#Weapons

The server also receives events for giving, removing and firing weapons, such as giveWeaponEvent. Cheaters who give themselves weapons trigger these. If your inventory handles weapons, compare what the event wants to give with what the player owns, and cancel it when it does not match. Log first, enforce later, so you do not block real players by accident.

Other game events exist for fire, projectiles and weapon damage. Look them up in the Cfx documentation before using one, and test on a development server.

Warning: a game event handler that is too strict punishes honest players. Start in log-only mode for a few days, read the logs, and then enforce.

#Layer 4: log suspicious behaviour

Do not ban on a single signal. Log, read, then act. A Discord webhook is an easy place to send logs that staff can see.

local WEBHOOK = GetConvar('anticheat_webhook', '')

local function logToDiscord(text)
    if WEBHOOK == '' then return end
    PerformHttpRequest(WEBHOOK, function() end, 'POST',
        json.encode({ username = 'Anticheat', content = text }),
        { ['Content-Type'] = 'application/json' })
end

AddEventHandler('explosionEvent', function(sender, ev)
    logToDiscord(('Explosion from %s (%s), type %s'):format(GetPlayerName(sender), sender, ev.explosionType))
end)

Set the webhook URL in server.cfg with set anticheat_webhook "https://...", not in the script, and keep it private. Anyone with the URL can post to your channel.

What to log: failed server-side checks (impossible amounts, wrong distance), blocked explosions, entity spawns you cancelled, repeated event spam. Include the player name, the server id and an identifier such as the license, so you can ban them.

#Layer 5: act with txAdmin

When the logs show a cheater, remove them. Use txAdmin to warn or ban, so the action is recorded and survives restarts. See moderating with txAdmin. In a script, DropPlayer(source, 'reason') kicks a player, but a ban should go through your moderation tools so identifiers are saved.

#What no anticheat can do

Be honest about the limits.

• The client belongs to the cheater. Anything checked only on the client can be switched off. Only server checks are reliable.
• No tool catches everything. New cheats appear, and detection is always a step behind.
• Obfuscation is not security. Hidden event names and "secret" tokens in client code can be read.
• Free or leaked anticheat code is a risk. Cheat developers read it too, and some of it contains backdoors. Be careful with resources from unknown sources.
• People still matter. Active staff, a clear report system and quick bans do more than any script.

Combine layers, keep resources updated, and review your logs. That makes your server a hard target compared with others.

#Checklist