The anti-cheat team is always trying to improve the anti-cheat, but sometimes things slip through.
In this guide we'll try to help cover some common-practice things you can do to make your server more secure.
Cheats can allow the client to trigger events in any context
context we mean they can execute client->server (via TriggerServerEvent) or client resource->client resource (via TriggerEvent)When working with events in Lua, it's crucial to register them correctly based on whether they are called by the client or the server.
A common mistake is registering server events that are not supposed to be called by the client, or vice-versa, which can lead to security vulnerabilities.
AddEventHandlerUse AddEventHandler when the event is intended to be triggered within the same context, either client-client or server-server. This ensures that the events are not networked and cannot be called by the opposing side.
AddEventHandler("eventName", function(eventParam1, eventParam2)
-- Code here will be executed once the event is triggered within the same context.
end)
RegisterNetEventUse RegisterNetEvent when the event needs to be triggered across different contexts, such as from client to server or server to client.
NOTE: This doesn't block execution from the same context, under the hood RegisterNetEvent is a wrapper that is just the following
RegisterNetEvent("eventName")
AddEventHandler("eventName", function()
end)
RegisterNetEvent("eventName", function(eventParam1, eventParam2)
-- Code here will be executed once the event is triggered across different contexts.
end)
This example is for the client, this example is not bullet proof as with anything on the client, it can be manipulated by cheating clients.
If you want to block execution from the same context, you should register your event like so:
RegisterNetEvent("eventName", function(eventParam1, eventParam2)
-- server will send net id `65535` for events from the server
if source ~= 65535 then return end
end)
You can learn more on this guide.
Even if you build a strong anti-cheat, adding checks on server events makes them more secure. This is a good practice, although it doesn't prevent everything. Below, we will share some good tips.
When using networked events, make sure to add some checks like:
Make sure to retrieve all values using server-side methods, not allowing players to change the values.
This ensures the integrity and security of your game environment. Please note that client checks can also be a good practice but can be easily be overridden.
All examples assume some kind of framework.
This is meant to show you bad ways of doing events, you should never do this.
RegisterNetEvent("job:givePlayerItem", function(item, count)
local ply = FX.GetPlayerFromSource(source)
-- directly adding items to the user from their own input
-- is always bad practice, you should always validate user input
ply.addItem(item, count)
end)
You can also check out this example resource for a more in-depth example with client and server examples.
-- coord is randomly made up
local VALID_JOB_COORD = vector3(125.0, 111.1, 35.83)
local MAX_ITEM_COUNT = 10
-- coord is randomly made up
local VALID_TURNIN_COORD = vecor3(1888.0, 1254.1, 48.0)
local ITEM_NAME = 'log'
-- list of players with active jobs
local activeJobs = {}
AddEventHandler("playerDropped", function ()
if not activeJobs[source] then return end
activeJobs[source] = nil
end)
function isPedWithinRange(ped, tgtCoords)
return #(GetEntityCoords(ped) - tgtCoords) < 15.0
end
-- handle incrementing the amount of items the ped would get server side
CreateThread(function()
while true do
for src, data in pairs(activeJobs) do
local ped = GetPlayerPed(source)
-- if they're not within range then we don't want to give them the item
if isPedWithinRange(ped, VALID_JOB_COORD) then
-- give them the item, but limit it to MAX_ITEM_COUNT
data.itemCount = math.min(data.itemCount + 1, MAX_ITEM_COUNT)
end
end
-- process job tick once per second
Wait(1000)
end
end)
RegisterNetEvent("job:startJob", function()
local ped = GetPlayerPed(source)
-- if they're within 15 units then they are doing the job
if isPedWithinRange(ped, VALID_JOB_COORD) then
activeJobs[source] = {
itemCount = 0,
}
end
end)
RegisterNetEvent("job:givePlayerItem", function()
local ply = FX.GetPlayerFromSource(source)
-- if they don't have an active job then they shouldn't be hitting this!
local jobData = activeJobs[source]
if not jobData then return end
-- they're not within range of the turn in coordinates, reject their changes
if not isPedWithinRange(ped, VALID_TURNIN_COORD) then return end
-- reset the item data so they can't trigger it multiple times
activeJobs[source] = nil
-- directly adding items to the user from their own input
-- is always bad practice, you should always validate user input
ply.addItem(ITEM_NAME, jobData.itemCount)
end)
Adhesive team is always working really hard to prevent cheaters to be able to use them. You will have most of those features enabled by default with FXServer 8450 build version and higher.
sv_kick_players_cnl_timeout_sec
This is the timeout at which the server will kick the player. (EX: if this is 600, kick them after 10 minutes of no CnL connection).
sv_kick_players_cnl_update_rate_sec
This is the frequency at which CnL is queried with the player list.
sv_pure_verify_client_settings
Replaces the periodic request to info.json in the client. Establishes a connection between adhesive<->svadhesive and verifies some of the sv_settings such as pureLevel, scripthook and other settings.
sv_kick_players_cnl_consecutive_failures
How many X's in a row do we need to see a player over the timeout_sec in order to Kick. The default is set to 2, indicating that if a player fails to check in for 10 minutes and then misses the next check-in update, they will be kicked. This serves as a failsafe mechanism.
sv_authMaxVariance
Variance is how likely the user's id will change for a given provider (i.e. 'steam', 'ip', or 'license'). You can learn about it here.
sv_authMinTrust
Trust is how unlikely it is for the user's identity to be spoofed by a malicious client. You can learn about it here.
sv_filterRequestControl
A console variable used to block REQUEST_CONTROL_EVENT routing based on a configurable policy. You can learn about the list here.
Having those convars active will likely get the player kick with the following reason:
Connection to CNL timed out.
Note: some error might occur but it's unlikely.
User getting kicked doesn't mean is automatically Global Ban. However, it provides an indication of player reliability, which can be useful for assessing trustworthiness.
We also have some other options:
sv_disableClientReplays
Enabling this will aim to reduce chances of cheating options. Please note that this will disable Rockstar Editor.
The codes provided are not supposed to be working on a copy/paste method. This is just some tips to prevent some actions that might happen in the server. This require some knowledge, you are always free to join our discord to get additionnal help.