Securing Server Events in FiveM Scripts: A Short Checklist
Most money and item exploits on FiveM servers come from the same mistake: a script trusts the client. A modder can trigger any network event with any arguments, so every server event has to assume the request might be fa
Most money and item exploits on FiveM servers come from the same mistake: a script trusts the client. A modder can trigger any network event with any arguments, so every server event has to assume the request might be fake. Here is a short checklist I run through on every script before it goes live.
1. Never accept amounts from the client
If a client event says "pay me 500", a modder will send "pay me 5000000". The server should decide the amount based on its own config.
-- bad
RegisterNetEvent('job:pay', function(amount)
Bridge.AddMoney(source, amount)
end)
-- better (Bridge.AddMoney is a small wrapper around your QBCore or ESX money function)
RegisterNetEvent('job:pay', function()
local src = source
Bridge.AddMoney(src, Config.Payout)
end)
2. Check job, distance and state
Before rewarding anything, check on the server that the player has the right job, is near the right location (#(GetEntityCoords(GetPlayerPed(src)) - Config.Location) < 5.0) and has actually started the task.
3. Add cooldowns
Store a timestamp per player and reject events that come in faster than a human could do the task. That stops looped triggers even if every other check passes.
4. Log suspicious calls
When a check fails, log the player identifier and event name. A few failed checks can be lag; hundreds per minute is someone injecting events.
5. Prefer scripts you can read
All of this is only possible to verify if you can open the code. With escrowed resources you have to trust the author got it right. Open source FiveM scripts let you check every event yourself before installing. xFiveM Shop publishes its QBCore, ESX and RedM resources unescrowed, and the setup steps are at xfivem.shop/help/installation.
Summary
Decide amounts on the server, validate job, distance and state, add cooldowns, log failures, and only run code you can read.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.