Contrôle d'accès et confidentialité

Comprendre quelles informations et actifs sont visibles pour les clients est crucial pour maintenir à la fois la sécurité et la confidentialité de votre expérience. 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 endroits "restreints" dans votre univers s'ils peuvent rejoindre un seul endroit. Ils peuvent voir tout le contenu répliqué à leur client, qu'il soit visible ou actuellement utilisé ou non. De plus, les exploitants peuvent décompiler n'importe quels 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 téléporter à n'importe quel endroit de cet univers, en contournant potentiellement toutes les restrictions d'accès ou les portes de progression prévues. Cela peut également entraîner la fuite non intentionnelle de contenu non publié, par exemple d'une expérience de développement ou de staging. 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
• Supposez que les exploitants découvriront l'existence de tous les sous-lieux dans votre univers
• Un client peut téléporter à n'importe quel sous-lieu s'il peut accéder à un seul endroit, tel que l'endroit racine, indépendamment de 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, car 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 un accès non autorisé par téléportation est de définir le Contrôle d'accès pour les Lieux sur Sécurisé uniquement dans l'univers dans le Tableau de bord Créateur. Cela restreint tous les endroits 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 leur est répliqué.

Pour des étapes de configuration et des conseils de migration pour les expériences existantes qui utilisent des téléportations initiées par le client, voir 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 supplémentaires de protection en plus d'elles, combinez les mesures suivantes :

• Conservez les lieux de développement et de test dans des univers privés séparés — c'est le seul moyen fiable d'assurer la confidentialité pour le contenu non publié. Ne jamais expédier d'actifs d'événement confidentiels, de scripts ou d'éléments UI vers l'environnement de production avant qu'ils ne soient destinés à être actifs.
• Si possible, utilisez le streaming pour limiter combien du monde se réplique à un nouveau joueur.
• Ajoutez une vérification des rôles de groupe ou des badges côté serveur et vérifiez l'état ou les exigences de progression du joueur.
• Par défaut, interdisez l'arrivée des joueurs entrants. Cela garantit qu'aucun joueur ne sera autorisé à entrer même si le processus de vérification est inconclusif, par exemple, 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 de tenter 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 soit répliquée 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 soit se réplique à tous les clients connectés, soit ne le fait pas. Il y a quelques exceptions, telles que le streaming.

Les conteneurs de réplication sont des instances de haut niveau (parendues 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 durée de 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 exploité 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éparé à 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 l'expérience jusqu'à une date ultérieure (ou à une autre condition), supposez que les exploitants trouveront un moyen de découvrir et de fuiter votre contenu dès qu'il est publié.

Évitez les 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 DataModel prévisible rend plus facile 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é à leur client, même si de tels scripts sont désactivés, jamais requis, ou jamais exécutés sur le client. Les scripts et ModuleScripts réservés au 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 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 exploitables.

ModuleScript original dans ReplicatedStorage
local module = {}

local Remote = script:WaitForChild("RemoteEvent")

-- Voici un exemple de 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

Résultat décompilé
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 incluant des mots de passe codés en dur, des règles commerciales et des 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 : Les items, cartes ou fonctionnalités non publiés peuvent être découverts et partagés publiquement avant les annonces officielles
• Désavantage concurrentiel : Des mécanismes, algorithmes ou fonctionnalités à venir peuvent être rétro-ingénierés par des concurrents
• Développement d'exploits : La logique serveur exposée rend plus rapide et plus facile pour les exploitants d'identifier des vulnérabilités et de développer des attaques ciblées