セキュリティとチート対策の戦術

具体的な安全な開発戦術やチート防止策に入る前に、Robloxセキュリティの基本原則を理解することが重要です。安全な体験は、敵対的な行動を予測するマインドセットに基づいて構築されています。コードの一行を書く前に、これらの基本原則を内面化する必要があります。これらは、あなたが行うすべてのアーキテクチャおよび設計の決定に影響を与えるべきです。

クライアントを信頼しない

これは基本的な原則です。決意の固い悪用者は、彼らのローカル状態とネットワークトラフィックを完全に制御しています。悪用者がこのレベルの制御を持っているため、クライアント側の施策に依存するセキュリティ対策は最終的に迂回されてしまいます。これはRobloxの限界ではなく、クライアント-サーバーアーキテクチャの fundamental reality です。クライアントから送信されたすべてのデータが操作され、偽造され、または悪意のある意図で送信されたと仮定してください。これには以下の力が含まれます：

• 複製された LocalScript や ModuleScript をデコンパイルすることができる（クライアントで実行されなくても）
• キャラクターやあらゆるアンカーされていないパーツのネットワーク所有権を取得する
• Touched イベントや ProximityPrompt アクティベーションなど、クライアントが開始したイベントを任意の範囲や頻度でトリガーする
• プレイヤーの位置、物理、または世界との相互作用を変更する
• RemoteEvents や RemoteFunctions を任意の頻度で任意の引数（最初の Player 引数を除く）で発火または呼び出す
• 期待されるイベントを発火することなく、ローカル DataModel 内の何かを変更する
• 任意にローカルで動作しているコードの動作を変更する

このため、すべての重要なロジックはサーバー側で検証するか、専らサーバー上で実行されるべきです。この制御の結果については、ネットワーク所有権、移動検証、および物理的な悪用 および アクセスポリシーと機密性 で詳述されています。

サーバーの権限

サーバーは、すべてのシミュレーション状態、ルール、プレイヤーの進行状況、および重要な決定の最終的な真実の源である必要があります。クライアントの役割は、世界をレンダリングし、ユーザー入力をサーバーに送信することです。

サーバーの役割は以下の通りです：

• クライアントからの入力を受信する
• 要求されたアクションが可能かつ許可されていることを検証する
• アクションを実行し、その権威ある状態を更新する
• 結果をすべての関連クライアントに複製する

例えば、プレイヤーが「Bloxy Colaを買いたい」と言った場合、サーバーはアイテムの真の価格、プレイヤーのお金、そしてプレイヤーキャラクターのショップからの物理的距離を知る必要があり、トランザクションを検証し承認する必要があります。可能な限り、検証される状態はサーバーによってのみ維持され、クライアントによっては維持されないべきです。例のように、Bloxy Colaの取引が承認された場合、サーバーはプレイヤーのお金からBloxy Colaの価格を差し引く必要がありますが、サーバーがプレイヤーキャラクターを常に制御できるわけではありません。

デザインによるセキュリティ

後から考えつきでセキュリティを追加するのではなく、初めから体験のデザインにセキュリティの考慮を組み込むべきです。

• 新しい機能ごとに脅威モデルを作成します。新機能ごとに以下を問いかけてください

  • 攻撃者がクライアントを完全に操作できる場合、どうやって悪用できるか？
  • クライアントがその機能で使用される任意のパラメーターに対して任意の値を送信できた場合、最悪の結果は何か？
  • この機能が1秒あたり1,000回以上使用された場合はどうなるか？最大使用頻度はどのくらいか？
  • 悪用者がこれを使って他のプレイヤーの体験を台無しにできるか？
  • 最悪のケースで、この機能が実際に使用するリソースはどのくらいか？
  • この機能のために公開する必要がある最低限の内部情報や状態は何か？
• 責任を早めに分担する。初日から、ロジックとデータを ServerScriptService に保持してください。それらを ReplicatedStorage や Workspace のような複製コンテナに置かないでください。