Ce qu'il envoie

Même quand l'expéditeur est le bon, ce qu'il envoie reste suspect.

Le serveur connaît les règles, pas le client

Une boutique dont le client envoie le prix :

RegisterNetEvent('boutique:acheter', function(article, prix)
    argent[source] = argent[source] - prix      -- prix = -1000000 ?
end)

Un prix négatif, et l'achat rapporte de l'argent. Le prix, la quantité maximale, le stock, le salaire : tout ce qui relève des règles du jeu est décidé par le serveur, à partir de ses propres tables. Le client ne peut qu'exprimer une intention (« je veux acheter du pain »).

local PRIX = { pain = 5, eau = 3 }

-- le client dit QUOI ; le serveur décide COMBIEN
local prix = PRIX[article]
if not prix then return end          -- article inconnu : on ignore

Le type d'abord

Lua ne vérifie pas les types. Si un gestionnaire attend un texte et reçoit une table, un nombre ou nil, la première opération de texte provoque une erreur :

plaque:upper()     -- attempt to index a table value

Au mieux, le gestionnaire s'arrête avec une erreur dans la console. Au pire, il s'arrête au milieu d'une opération, après avoir retiré l'argent mais avant d'avoir livré l'objet. On vérifie donc le type, puis les bornes, puis le format, avant de toucher à quoi que ce soit :

if type(texte) ~= 'string' then return end
if #texte < 1 or #texte > 8 then return end
if not texte:match('^[%w ]+$') then return end    -- lettres, chiffres, espaces

tonumber rend le même service pour les nombres : il renvoie nil pour tout ce qui n'en est pas un.

Refuser en silence

Face à une requête invalide, le gestionnaire sort sans rien faire (return). Un joueur honnête n'enverra jamais ces valeurs ; les refuser poliment n'apporte rien, et expliquer à un tricheur ce qui a échoué l'aide.