Contrôle d'accès et confidentialité

Comprendre quelles informations et actifs sont visibles par les clients est essentiel pour maintenir à la fois la sécurité et la confidentialité de votre jeu. Les développeurs sous-estiment souvent combien de choses sont visibles pour les exploitants et répliquées aux clients. Les exploitants ont la capacité d'accéder à des lieux "restreints" au sein de votre univers s'ils peuvent rejoindre un seul lieu. Ils peuvent voir tout contenu répliqué à leur client, qu'il soit visible ou actuellement utilisé ou non. De plus, les exploitants peuvent décompiler tous les scripts locaux et ModuleScripts répliqués, même s'ils ne sont jamais exécutés sur le client.

Téléportation côté client au sein des univers

Une fois à l'intérieur d'un univers, les clients peuvent se téléporter à n'importe quel lieu au sein de cet univers, contournant potentiellement toutes les restrictions d'accès ou portes de progression prévues. Cela peut également entraîner la fuite involontaire de contenu non publié, par exemple d'un jeu de développement ou de mise en scène. Il est important de comprendre que :

• Désactiver "Accès direct" ne supprime que le bouton Rejoindre des sous-lieux sur le site web — cela ne prévient pas les téléportations initiées par le client
• Supposer que les exploitants découvriront l'existence de tous les sous-lieux au sein de votre univers
• Un client peut se téléporter à n'importe quel sous-lieu s'il peut accéder à un seul lieu, comme le lieu racine, peu importe votre flux de conception prévu

De nombreux développeurs tentent de prévenir l'accès en expulsant les utilisateurs non autorisés d'un sous-lieu. Cela peut fonctionner pour bloquer le gameplay, mais cela ne prévient pas la réplication de contenu au client, puisque la réplication commence dès que le joueur rejoint et avant que la logique d'expulsion côté serveur puisse s'exécuter.

Utilisez des téléportations sécurisées

Le moyen le plus efficace de prévenir l'accès non autorisé via la téléportation est de définir le Contrôle d'accès pour les lieux sur Sécurisé uniquement au sein de l'univers dans le Tableau de bord du créateur. Cela restreint tous les lieux non de départ aux téléportations initiées par le serveur uniquement, bloquant les téléportations initiées par le client au niveau de la plateforme avant que le joueur ne rejoigne jamais le sous-lieu. Comme le joueur ne rejoint jamais, aucun contenu ne se réplique à lui.

Pour les étapes de configuration et les conseils de migration pour les jeux existants qui utilisent des téléportations initiées par le client, consultez Téléportation entre les lieux.

Défense en profondeur pour les lieux restreints

Pour les univers qui ne peuvent pas utiliser des téléportations sécurisées, ou comme couches de protection supplémentaires à côté d'elles, combinez les mesures suivantes :

• Conservez les lieux de développement et de test dans des univers séparés et privés — c'est le seul moyen fiable d'assurer la confidentialité du contenu non publié. Ne jamais expédier d'actifs d'événements confidentiels, de scripts ou d'éléments d'interface utilisateur dans l'environnement de production avant qu'ils ne soient destinés à être actifs.
• Si possible, utilisez le streaming pour limiter la quantité de monde qui se réplique à un nouveau joueur.
• Ajoutez une vérification de rôle de groupe côté serveur ou de badge et vérifiez l'état ou les exigences de progression du joueur.
• Par défaut, interdire l'entrée des joueurs entrants. Cela garantit qu'aucun joueur ne sera autorisé à entrer même si le processus de vérification est inconclusif, comme dans le cas d'une exception lancée par le moteur.
• Si pratique, utilisez l'API Ban pour les joueurs qui échouent à la validation. Cela empêche les joueurs d'essayer continuellement de rejoindre avec le même compte.

Réplication

La réplication décrit comment l'état se transfère sur le réseau entre les instances du moteur. Le modèle de réplication de Roblox est généralement simplifié de quelques manières clés :

• Les instances sont autorisées par le serveur, ce qui signifie que pour qu'une instance se réplique entre tous les participants (le serveur et tous les clients connectés), elle doit être créée sur le serveur.
• Les propriétés des instances sont également autorisées par le serveur, ce qui signifie que la plupart des propriétés doivent être modifiées sur le serveur pour que les changements soient visibles sur tous les clients.
• En général, une instance se réplique soit à tous les clients connectés, soit ne se réplique pas. Il existe quelques exceptions, comme le streaming.

Les conteneurs de réplication sont des instances de niveau supérieur (parentées sous le DataModel) qui se répliquent aux clients. Si une instance devient un descendant d'un conteneur de réplication au cours de sa vie, vous devez vous attendre à ce qu'une grande partie de son état se réplique à tous les clients. Vous pouvez en savoir plus sur les conteneurs de réplication courants dans le guide du modèle de données. En cas de doute, vous pouvez toujours vérifier comment une instance ou une propriété se réplique dans un environnement de test tel que Play Solo. Vous pouvez en savoir plus sur les modes de test dans Modes de test Studio.

Implications de sécurité de la réplication

Tout contenu qui se réplique à un client peut être extrait et analysé par un exploitant. En règle générale, évitez de publier ou d'expédier tout contenu confidentiel dans l'environnement de production en direct à moins que vous ne soyez immédiatement prêt à ce qu'il soit vu par les utilisateurs. Même s'il existe une logique qui verrouille la publication ou l'accès au contenu dans le jeu jusqu'à une date ultérieure (ou une autre condition), supposez que les exploitants trouveront un moyen de découvrir et de divulguer votre contenu dès qu'il est publié.

Évitez des noms trop descriptifs ou prévisibles pour les instances sensibles, y compris mais sans s'y limiter : scripts, distants et modèles. Avoir une hiérarchie de DataModel prévisible facilite le développement d'exploits.

Décompilation de scripts

Tout LocalScript, Script avec RunContext::Client, ou ModuleScript peut être décompilé par un exploitant une fois répliqué à son client, même si ces scripts sont désactivés, jamais requis ou jamais exécutés sur le client. Les scripts et ModuleScripts uniquement côté serveur stockés dans ServerStorage ou ServerScriptService ne peuvent pas être décompilés car ils ne se répliquent jamais aux clients.

Écrire un ModuleScript qui inclut du code uniquement côté serveur et côté client dans le même script est déconseillé car la logique côté serveur sera exposée lors de la décompilation et pourra être plus facilement disséquée pour des bugs pouvant être exploités.

local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Voici un exemple d'un paradigme à éviter
-- Gardez le code serveur dans des instances de Script ou dans ServerStorage/ServerScriptStorage !

if game:GetService("RunService"):IsServer() then
  function module:DoServerThing(password)
    if password == "SecretPassword" then
      print("code serveur sensible")
    end
  end

  Remote.OnServerEvent:Connect(function(player, password)
    module:DoServerThing(password)
  end)
else
  function module:DoServerThing(password)
    Remote:FireServer(password)
  end
end

return module

local table1 = {};
local RemoteEvent = script:WaitForChild("RemoteEvent");
if game:GetService("RunService"):IsServer() then
  function table1.DoServerThing(_, p2) -- Ligne : 9
    if p2 == "SecretPassword" then
      print("code serveur sensible");
    end
  end
  RemoteEvent.OnServerEvent:Connect(function(player: Player, p3) -- Ligne : 15
    --[[
      Upvalues:
        [1] = table1
    --]]
    table1:DoServerThing(p3);
  end);
  return table1;
end
function table1.DoServerThing(_, p1) -- Ligne : 19
  --[[
    Upvalues:
      [1] = RemoteEvent
  --]]
  RemoteEvent:FireServer(p1);
end
return table1;

Comme montré ci-dessus, la décompilation révèle la logique côté serveur, y compris les mots de passe codés en dur, les règles commerciales et les détails d'implémentation que les exploitants peuvent analyser pour détecter des vulnérabilités.

Impact des violations de confidentialité

Les violations de confidentialité peuvent avoir des conséquences significatives, telles que :

• Fuites de contenu : Des éléments, cartes ou fonctionnalités non publiés peuvent être découverts et partagés publiquement avant les annonces officielles
• Désavantage concurrentiel : Des mécaniques, algorithmes ou fonctionnalités à venir peuvent être rétro-conçus par des concurrents
• Développement d'exploits : La logique serveur exposée facilite et accélère l'identification des vulnérabilités par les exploitants et le développement d'attaques ciblées