Raven AnticheatRavenAnticheat
The Raven JournalNovember 22, 2024 · 6 min

Detection · Server

Why server-side event validation is non-negotiable in 2025

TriggerServerEvent abuse is the cheapest exploit on FiveM. Client-side anticheat alone cannot stop it. Here's why.

Most economy exploits on a FiveM server come down to one mistake: a server-side event handler that trusted whatever the client sent it. Client-side anticheat matters, but on its own it cannot stop this kind of attack.

FiveM exposes server-side event handlers through TriggerServerEvent. Any connected client can call any registered event with any arguments it wants. That is not a bug, it is how the networking model works. The danger starts when a handler treats those arguments as if a normal client sent them in good faith.

The exploit, in two lines

Here is the kind of handler that gets servers wiped:

server.lua (vulnerable)
RegisterServerEvent('shop:buy')
AddEventHandler('shop:buy', function(itemId, price)
    local src = source
    -- Trusts the client to send the right price.
    exports.ox_inventory:AddItem(src, itemId, 1)
    Player(src).state.cash = Player(src).state.cash, price
end)

A cheater calls TriggerServerEvent('shop:buy', 'weapon_combatpdw', 0) and walks off with a free weapon. No injector, no aimbot. Just a one-line script that any Lua executor can run.

The fix is to validate on the server:

server.lua (validated)
RegisterServerEvent('shop:buy')
AddEventHandler('shop:buy', function(itemId)
    local src = source
    local item = ITEM_CATALOG[itemId]
    if not item then return end          -- unknown item id
    if not isPlayerNearShop(src) then return end  -- not at a shop
    local cash = Player(src).state.cash
    if cash < item.price then return end  -- can't afford
    exports.ox_inventory:AddItem(src, itemId, 1)
    Player(src).state.cash = cash, item.price
end)

The handler now reads the price from a server-controlled catalog, checks that the player is near a shop, and confirms they can pay. None of the client's input is trusted on its own.

Why client-side anticheat does not save you

Client-side anticheat scans memory for known cheat signatures and kicks flagged players. That catches aimbots, ESP, and Lua executors before they fire an event, and it is worth running. But it is a probabilistic defense. A cheat that has not been signatured yet, or one that runs from outside the FiveM process, can fire a single legitimate-looking TriggerServerEvent that your client-side scan never sees.

Server-side validation does not rely on spotting the cheat. It relies on the handler refusing to behave in a vulnerable way, no matter what the client is. That is structural, not probabilistic. It needs no updated signature, and the next cheat release does not bypass it.

What "validate everything" means in practice

Run every server-side event handler through this checklist:

  • Identity: never take a player ID from the client. Use source directly.
  • Authority: read the state the player should have (job, location, inventory) from your own server data, not from the event arguments.
  • Bounds: if the client sends a number, check it sits within sane limits. A money amount of 999,999,999 is not a real purchase.
  • Rate: the same player calling shop:buy 200 times a second is a script, not a human. Throttle handlers that are cheap to spam.
  • Catalog lookups: when the client sends an ID, look it up in a server-side catalog and pull everything else (price, weight, properties) from there.

Where an anticheat actually helps

A good FiveM anticheat does not replace handler validation. What it does is raise the cost of attacks against the handlers you have not hardened yet:

  • Per-player event rate limiting that catches a cheater spamming an event before the first batch of fraudulent calls goes through.
  • Trust scoring that downgrades players whose event patterns drift from the norm and flags them for admin review.
  • Argument-shape monitoring that catches events called with values outside their historical range.

These run server-side, independent of the client. They are also the features most likely to catch a novel attack before your handlers have been audited, which is the real state of any server that has been live for more than a year.

If you are evaluating an anticheat, ask the vendor what server-side telemetry it collects, which events it rate-limits out of the box, and how trust scoring is calculated. If the answer is mostly about client-side scanning, you are buying half a product.

How Raven handles event protection

Raven's ServerEventsProtection and ClientEventsProtection ship with an event-shape classifier layered on top of per-event allowlists. Cheat-shaped names like setMoney, giveAdmin, spawnVehicle, and runCode are blocked no matter which resource emits them. Raven Mind's classifier flags new cheat-shaped names as they show up, with no operator writing a rule. When the same resource keeps producing the same false-positive shape, the Mind resource consolidator proposes a single resource-level allowlist to replace forty event-level ones, and it waits for operator approval before applying anything. That wait is the difference between a static blacklist and an event layer that learns.

Keep reading03