CSRでは絶対情報が漏れる？──APIキー・秘密情報の安全設計ガイド
目次
- はじめに
- CSRとは
- SSRとは
- CSRでは絶対情報が漏れる理由
- じゃあCSRは一般公開に使えないのか？
- その前提で設計と実装が必要
- FirebaseやSupabaseの例
- Kintoneの例
- まとめ：ブラウザに渡す情報について
はじめに
「ブラウザで直接動くアプリ（CSR: Client-Side Rendering）では、どうしても情報が漏れる」と聞いたことはありませんか？
これは単なる噂ではなく、技術的に避けられない事実です。
この記事では、まずCSRとSSRの違いを整理し、そのうえで「なぜ漏れるのか」「どう設計すれば安全か」を解説します。
CSRとは
CSR（Client-Side Rendering）は、HTMLやJavaScriptをブラウザで実行して画面を描画する方式です。
代表的なフレームワーク：React, Vue, Angular など。
特徴
- ページの動的更新が得意
- 初回表示は遅くなりやすい（JSの読み込み後にレンダリング）
- サーバー負荷が低い
- クライアントに渡した情報はすべて見られる
SSRとは
SSR（Server-Side Rendering）は、サーバーがあらかじめHTMLを生成してブラウザに送る方式です。
代表的なフレームワーク：Next.js（React）、Nuxt.js（Vue）など。
特徴
- 初回表示が速い（完成HTMLを返すため）
- SEOに有利（クローラーが読み取りやすい）
- サーバー負荷は高め
- サーバー側だけで処理できるため、機密情報を守りやすい
CSRでは絶対情報が漏れる理由
- ブラウザで動くJavaScriptはユーザーの端末上で実行される
- 開発者ツール（DevTools）でソース・変数・ネットワーク通信が丸見え
- HTTPSでも「受け取った後」の情報は見られる
つまり、クライアントに渡した時点で、それは「相手が自由に見られる」状態になるということです。
じゃあCSRは一般公開に使えないのか？
いいえ、使えます。
ただし、使い方に制限があります。
危険になる例：
- APIキーやパスワードを直接埋め込む
- クライアントだけでアクセス制御を完結させる
安全に使うための例：
- 公開しても問題ない情報だけブラウザに渡す
- 機密情報は必ずサーバーで処理
- APIアクセスはバックエンド経由にする
その前提で設計と実装が必要
設計時のチェックリスト：
- ブラウザに渡す情報は「見られても困らない」か？
- APIキーはサーバーだけが知っているか？
- 書き込みや重要処理はサーバー経由か？
- 公開用キーやトークンの権限は最小限か？
FirebaseやSupabaseの例
- 公開キー（anon key / API key）は漏れる前提
- 実際の安全性は セキュリティルール（Firebase） や RLSポリシー（Supabase） で確保
- 管理者キー（service key）は絶対にクライアントに置かない
- 「キーを守る」のではなく、「漏れても悪用できない」設計が基本
これって公開鍵のシステムに似てますよね。
Kintoneの例
- APIトークン発行時に権限を固定できる
- 読み取り専用なら漏れても被害は小さい
- 書き込み可能なら必ずサーバー経由
- Firebase/Supabaseと違い、キー自体に権限を持たせる方式
- 権限設定を誤ると、漏れた瞬間に被害発生の可能性あり
まとめ：ブラウザに渡す情報について
- CSRでは情報は必ず見られる → 機密は渡さない
- 公開して良い情報だけクライアントに置く
- 秘密情報はサーバーで保持し、結果だけ返す
- 各サービスのセキュリティモデルを理解し、それに合わせた運用をする
💡 鉄則
ブラウザに渡した瞬間、その情報は「公開された」と同じ。
守るべき情報は必ずサーバーに閉じ込める。