セキュリティモデル

Webアプリやゲームのコードは利用者のマシンで動き、誰でも読んだり書き換えたりできます。KUMODeckはこの事実を前提に設計されています。悪用できるものは、何ひとつブラウザに任せません。

秘密鍵は絶対にブラウザに入れない#

SDKにsk_の鍵を渡すとエラーになります。秘密鍵はCIのシークレットか、自分のサーバーの環境変数に置いてください。漏れた場合は、ダッシュボードで新しい鍵を作り、CIを更新して、古い鍵を失効させます。失効は即座に反映されます。鍵はハッシュで保存されるので、なくした鍵は復元できず、入れ替えるしかありません。

developmentとproductionは分離されている#

プレイヤー、データ、ルームは環境ごとに別々で、どの鍵もちょうど1つの環境に属します。pk_dev_の鍵はproductionのデータに触れられず、devの鍵が漏れても本物の利用者は露出しません。

改造されたクライアントにできること・できないこと#

設計のルール: 価値のあるものは、クライアント側のifではなく、サーバー側の判断（自分のFunctions）の後ろに置いてください。対戦型のマルチプレイでは、ホストを権威にするか、試合のロジックを自分のFunctionsで動かします。statsは反映前にサーバーで確認できます。値の範囲、送信の頻度、自分のサーバーへの署名つきwebhookです（integrity.stats。設定リファレンスを参照）。

プレイヤー#

• アクセストークン（JWT、15分）はデータベースに問い合わせずに検証します。リフレッシュトークン（90日）は使うたびに回転し、再提示されたトークンは系列ごと失効させます。
• パスワードはメモリハードなKDFでハッシュします。ログインのエラーから、そのメールが存在するかどうかはわかりません。
• 他の利用者のデータは見えません。自分のものでないリソースへのリクエストは404を返します。

ホスティング#

アプリやゲームは別の登録可能ドメイン（<slug>.kumodeck.app）から、プロジェクトごとに1つのサブドメインで配信します。そのため、プロジェクトのJavaScriptからダッシュボードのセッションや別のプロジェクトのlocalStorageは読めません。developmentのデプロイにはnoindexが付きます。

Functions#

あなたのサーバーのプログラムは、他のクリエイターのコードやKUMODeck自身から分離されて動きます。環境ごとに専用のデータベース、KV、ファイル、キューを持ち、コードが届くのは自分に割り当てられたリソースだけです。KUMODeck自身のシステムには、その環境用に発行された秘密鍵を通してしか届きません。シークレットの値はそのまま実行環境に渡され、KUMODeckが保存することはありません。生のTCPソケットはブロックされ、リクエストごとのCPUとサブリクエストに制限があります。

開発者アカウント#

• ログインはメールとパスワード、またはGoogle・GitHubで行えます。ダッシュボードのボタンは、サーバーの管理者が有効にしたものだけが出ます。ターミナルからはkumodeck login --google（または--github）で、ブラウザが開き、手元の127.0.0.1のポートでPKCEを使って待ちます（ghやgcloudと同じ方式）。別の端末で番号を打つ方式はありません。
• メールアドレスが同じというだけで、Google・GitHubのアカウントを既存のアカウントに自動では結び付けません。プロバイダの「確認済みのメール」は、そのアドレスの今の持ち主を保証しないためです。同じメールのアカウントが既にあるときは、いつもの方法でログインしてから、ダッシュボードのアカウント → ログイン方法で追加してください。
• ログイン方法の追加・解除、パスワードの設定、アカウントの閉鎖の前には、本人の確認（パスワード、または追加済みのプロバイダでのログインのやり直し）があります。ログイン方法を外す・パスワードを設定 / 変更すると、ほかの端末と接続中のツール（CLI・MCP）はログアウトされます。最後のログイン方法は外せません。

AIエージェントなどのMCPクライアント#

アシスタントは、同意画面であなたが選んだスコープとプロジェクトの範囲で動きます。productionの変更、BAN、削除は、アシスタントがツールを自動承認する設定でもあなたの確認が必要です。AIエージェントから使うを参照してください。

脆弱性の報告#

セキュリティの問題は、公開のissueではなく、メンテナーに非公開で報告してください。