Le contenu suivant couvre divers concepts et tactiques pour améliorer la sécurité et atténuer la tricherie dans vos expériences Roblox. Il est fortement recommandé à tous les développeurs de lire cela afin de s'assurer que vos expériences sont sécurisées et équitables pour tous les utilisateurs. Consultez la barre latérale pour d'autres sujets de sécurité.
Avant de plonger dans des tactiques spécifiques pour développer de manière sécurisée et prévenir la tricherie, il est essentiel de comprendre les principes fondamentaux de la sécurité Roblox. Une expérience sécurisée repose sur un état d'esprit qui anticipe les actions d'adversaires. Avant d'écrire une seule ligne de code, vous devez intérioriser ces principes fondamentaux. Ils doivent informer chaque décision architecturale et de conception que vous prenez.
Ne jamais faire confiance au client
C'est le principe fondamental. Un exploiteur déterminé a un contrôle total sur son état local et son trafic réseau. En raison de ce niveau de contrôle, toute mesure de sécurité reposant sur l'application côté client sera finalement contournée. Ce n'est pas une limitation de Roblox : c'est une réalité fondamentale des architectures client-serveur. Supposer que chaque morceau de données envoyé par le client a été manipulé, fabriqué ou envoyé avec une intention malveillante. Cela inclut le pouvoir de :
- Décompiler tout LocalScript ou ModuleScript répliqué, même s'ils ne s'exécutent jamais sur le client
- Prendre possession du réseau de leur personnage et de toutes les pièces non ancrées
- Déclencher des événements initiés par le client tels que des événements Touched ou des activations de ProximityPrompt à toute distance ou fréquence
- Modifier la position de leur joueur, leur physique ou leurs interactions avec le monde
- Déclencher ou invoquer des RemoteEvents et RemoteFunctions à toute fréquence avec des arguments arbitraires (excepté le premier argument Player)
- Changer quoi que ce soit dans leur DataModel local sans déclencher d'événements prévus
- Altérer arbitrairement le comportement de tout code s'exécutant localement
En raison de cela, toute logique critique doit être validée sur le serveur ou s'exécuter exclusivement sur le serveur. Les conséquences de ce contrôle sont détaillées dans Network Ownership, Movement Validation, and Physics Exploits et Access Control and Confidentiality.
Autorité du serveur
Le serveur doit être la source ultime de vérité pour tous les états de simulation, règles, progression des joueurs, et décisions critiques. Le rôle du client est de rendre le monde et d'envoyer des entrées utilisateur au serveur.
Le rôle du serveur est de :
- Recevoir des entrées du client
- Valider que l'action demandée est possible et permise
- Exécuter l'action et mettre à jour son état autoritaire
- Répliquer les résultats à tous les clients concernés
Par exemple, si un joueur dit "Je veux acheter un Bloxy Cola", le serveur doit connaître le vrai prix de l'objet, l'argent du joueur, et la distance physique du personnage du joueur par rapport au magasin avant de valider et d'approuver la transaction. Autant que possible, l'état à valider doit être maintenu exclusivement par le serveur et non par les clients. Dans l'exemple, si la transaction du Bloxy Cola est approuvée, le serveur doit soustraire le prix du Bloxy Cola de l'argent du joueur, cependant, le serveur ne peut pas nécessairement toujours contrôler le personnage du joueur.
Sécurité par design
Intégrez les considérations de sécurité dans la conception de votre expérience dès le départ, plutôt que d'essayer de les ajouter plus tard en tant qu'après-coup.
- Modélisez les menaces de chaque nouvelle fonctionnalité. Pour chaque nouvelle fonctionnalité, demandez-vous :
- Comment un attaquant pourrait-il exploiter cela s'il a un contrôle total de son client ?
- Si un client pouvait envoyer n'importe quelle valeur pour n'importe quel paramètre utilisé dans la fonctionnalité, quel serait le pire scénario possible ?
- Que se passe-t-il si cette fonctionnalité est utilisée plus de 1 000 fois par seconde ? Quelle est le taux maximum auquel elle devrait être utilisée ?
- Un exploiteur pourrait-il utiliser cela pour ruiner l'expérience d'un autre joueur ?
- Quelles ressources, dans le pire des cas, cette fonctionnalité pourrait-elle raisonnablement utiliser ?
- Quelle est la quantité minimale d'informations ou d'état interne que je dois exposer pour cette fonctionnalité ?
- Partitionnez les responsabilités tôt. Gardez la logique et les données dans ServerScriptService dès le premier jour. Ne les placez jamais dans des conteneurs répliqués comme ReplicatedStorage ou Workspace.