Les tricheurs abusent des événements réseau pour s'octroyer de l'argent, faire apparaître des véhicules et obtenir des objets. Voici comment fonctionnent les exploits de triggers FiveM, pourquoi ils sont si difficiles à auditer à la main, et comment Trigger Finder de ZeroTrust cartographie et signale toute votre surface d'attaque d'événements.
Si vous gérez un serveur FiveM depuis un moment, vous connaissez ce problème : un joueur avec un menu de triche s'octroie de l'argent, fait apparaître des véhicules ou remplit son inventaire d'objets, sans jamais toucher à l'interface prévue. Il ne casse pas le moteur du jeu : il appelle directement les événements réseau de votre serveur.
C'est la façon la plus courante dont les serveurs FiveM sont exploités, et « sécurisez vos événements » est le conseil habituel. Le souci, c'est que ce conseil suppose que vous savez déjà quels événements sont exposés. Sur un serveur qui fait tourner des dizaines de ressources, presque personne ne le sait. Cet article explique comment fonctionnent les exploits de triggers, pourquoi ils sont si durs à corriger à la main, et comment nous avons transformé tout ce problème en un outil : Trigger Finder.
Dans FiveM, les scripts communiquent entre le client et le serveur via des événements réseau. Un client appelle TriggerServerEvent et le serveur exécute le handler enregistré pour ce nom d'événement. C'est exactement ainsi que fonctionne le jeu légitime, et exactement ce dont un tricheur abuse.
Un menu de triche peut déclencher n'importe quel événement réseau enregistré par votre serveur, avec les arguments qu'il veut. Si une ressource possède un événement serveur qui ajoute de l'argent, donne un objet ou fait apparaître un véhicule et qu'il fait confiance aux valeurs envoyées par le client, le tricheur l'appelle simplement directement :
-- Vulnérable : le serveur fait confiance à tout ce que le client envoie
RegisterNetEvent("shop:buyItem", function(item, amount)
local ply = FX.GetPlayerFromSource(source)
-- Aucune vérification de prix, aucune validation — le client contrôle tout
ply.addItem(item, amount)
end)
-- Un tricheur appelle simplement :
-- TriggerServerEvent("shop:buyItem", "gold_bar", 9999)Corriger un événement isolé est bien compris : valider côté serveur, ne jamais faire confiance aux entrées du client. Nous détaillons les modèles exacts dans notre Guide de sécurité des événements Lua FiveM. Le plus dur n'est pas de corriger un événement, c'est de savoir où ils se trouvent tous.
Un serveur roleplay typique fait tourner de 50 à plus de 300 ressources, dont beaucoup de scripts tiers que vous n'avez pas écrits. Chacun peut enregistrer des dizaines d'événements réseau, soit potentiellement des milliers d'événements, éparpillés dans des fichiers que vous n'avez jamais ouverts. On ne peut pas sécuriser ce qu'on ne voit pas, et personne ne va lire manuellement chaque ressource à la recherche d'un handler addMoney oublié.
Plutôt que de publier encore de la documentation, nous avons intégré l'audit directement dans le panneau ZeroTrust. L'idée était simple : si la partie dangereuse d'un serveur est sa surface d'événements, alors chaque propriétaire devrait pouvoir voir toute cette surface d'un coup d'œil, classée par risque, avec un chemin direct vers chacun.
Trigger Finder est un scanner intégré au tableau de bord ZeroTrust. Vous lancez un scan initié par le serveur, et il parcourt vos ressources pour en extraire chaque événement et trigger trouvé, en étiquetant chacun avec sa ressource, son fichier, son numéro de ligne, son côté (client ou serveur) et son nom d'événement.
Au lieu de deviner, vous obtenez un inventaire complet et consultable de chaque événement réseau exposé par votre serveur. Chaque trigger est enregistré avec son emplacement et son sens de circulation — Client → Serveur, Serveur → Client, Client → Client ou Serveur → Serveur — afin de voir immédiatement lesquels sont accessibles à un client malveillant.
Le résultat est une répartition des risques pour tout votre serveur : combien de triggers sont sûrs ou critiques, quelles ressources contiennent le plus d'événements dangereux, et comment tout se répartit entre client et serveur.
Chaque résultat renvoie à sa ressource → fichier → ligne, avec une vue de contexte de code pour lire le trigger sur place. Quand Trigger Finder signale un handler addItem dangereux, vous savez exactement quel script et quelle ligne renforcer, sans avoir à chercher.
Chaque serveur est différent, surtout avec des frameworks personnalisés. Vous pouvez configurer vos propres mots-clés et votre liste d'événements dangereux, pour que Trigger Finder signale les noms de fonctions qui comptent pour vos scripts, pas seulement ceux par défaut.
Trigger Finder vous dit quoi sécuriser. L'étape suivante consiste à combler l'écart : validez chaque événement signalé côté serveur, récupérez les valeurs via des méthodes côté serveur au lieu de faire confiance au client, et vérifiez l'état, la position et les permissions du joueur avant d'agir. Tous les modèles — ainsi que les convars de sécurité FXServer à activer — figurent dans notre Guide de sécurité des événements Lua FiveM.
On ne peut pas défendre une surface d'attaque qu'on n'a jamais vue. Trigger Finder transforme le conseil vague « sécurisez vos événements » en une liste de contrôle concrète générée à partir de votre véritable serveur, pour savoir précisément ce qui est exposé et où le corriger.