🛡️ サーバー運用とセキュリティ

なぜ「アプリ完結」では不十分なのか？

本プラグインでは、「Secret Generator」によって重要情報をC++ネイティブプラグイン化し、バイナリ解析への耐性を高めています。しかし、これはあくまで第一防衛線に過ぎません。

C++プラグインによる保護は「隠蔽」です。情報を読みにくくしますが、データ自体は端末内に存在します。一方で、サーバー運用は情報の 「隔離」 を可能にします。

アプリ完結型: Webhook URLやAPIキーがバイナリ内に含まれる。一度抽出されると、攻撃者はそのキーを使い放題になる
サーバー経由型: アプリは「共通の鍵（Shared Secret）」しか持たず、真に守るべき情報（DiscordのURL、Slackトークン、メールサーバーの認証情報）はサーバーの中にだけ存在します

もし万が一、端末内の「Shared Secret」が解析によって漏洩したとしても、サーバーがあれば以下の防衛措置が瞬時に機能します。

流量制限（Rate Limiting）: 1分間に100回送るようなスパム攻撃を、IPやReporter ID単位で遮断します。アプリ完結型では、攻撃者が直接Webhookを叩くのを止める術がありません。
認証の無効化: アプリをアップデートすることなく、サーバー側の設定一つで漏洩したトークンを無効化したり、新しい鍵に差し替えたりできます。
動的なブラックリスト: 特定の悪質ユーザー（Reporter ID）をサーバー側で即座にBANできます。

サーバー構成では、リクエストごとに HMAC（Hash-based Message Authentication Code） による署名検証を行います。

これにより、単にパケットをコピーして再送する「リプレイ攻撃」や、送信内容を勝手に書き換える「改ざん」を防ぎます。サーバーはこの署名が正しい場合のみ、外部サービス（Discord等）へリクエストを転送します。

「端末にあるものは、いつか盗まれる」。この前提に立ち、盗まれても致命傷にならない設計にする。それこそが、サーバー構成の最大の利点です。

もちろん、クローズドな開発環境であれば「アプリ完結型」の手軽さは大きな武器になります。しかし、開発チーム以外の外部テスターを招く場合や、パブリックなベータテストなど、自分たちの目が届かない範囲にアプリが広がるフェーズでは、このサーバー構成が強力な安心材料になります。

「もしも」の時のリスクヘッジをサーバーに任せることで、開発者は安心してフィードバックの収集と改善に集中できるようになります。