Zenn
🙆

【Day12】FirestoreセキュリティルールとUXの両立を考える

に公開
Firebase
Firestore
個人開発
セキュリティルール
ux改善
tech

【Day12】FirestoreセキュリティルールとUXの両立を考える

こんにちは、Keisukeです。
個人開発の連続投稿もついにDay12！
今回は、Firestoreのセキュリティルールとユーザー体験（UX）の両立について考えてみました。

🔐 セキュリティルールとは？

Firestoreでは、誰がどのデータを「読み書きできるか」を細かく制御するために、セキュリティルールを設定します。

これはアプリの安全性を守るために必須の設定ですが、
一方で「ユーザーにとって使いにくくなる」リスクも孕んでいます。

🧪 実際に起きた問題

開発中、以下のようなことがありました：

  • ログインしていないと一覧画面が読み込めない
  • ユーザー本人しか自分の投稿を見れない
  • Firestoreからのpermission-deniedエラーで画面が真っ白に

こうした体験は、セキュリティが強すぎるがゆえのUX低下を招きかねません。

🔧 解決策と工夫

✅ 1. 公開情報と非公開情報を分ける

match /posts/{postId} {
  allow read: if true; // 誰でも閲覧OK
  allow write: if request.auth != null && request.auth.uid == resource.data.uid;
}
  • 一覧表示用の「投稿データ」は全員にread許可
  • 編集や削除はログイン中かつ本人のみ

✅ 2. UI側でエラー制御を徹底

try {
  const snapshot = await getDocs(query(...));
  // 表示処理
} catch (e) {
  console.error("データ取得失敗:", e.message);
  setError("表示できませんでした。ログイン状態をご確認ください。");
}
  • 「表示できません」などUXを壊さないメッセージ表示を意識
  • onSnapshotなどリアルタイム取得時もtry-catchを丁寧に

✅ 3. 開発中はrules_version = '2';で最小構成から始める

ルールを徐々に細かくしながら、アプリの動作と照らし合わせてテストしていくのが吉。

💡 UXとセキュリティは対立しない

一見、「セキュリティを強くする = UXが悪くなる」と思いがちですが、

  • 必要な情報だけを見せる
  • 必要な操作だけを許す

というのは、実はユーザーにとっても“安心”につながる体験です。

📌 今後やってみたいこと

  • 投稿データに「公開・非公開」フラグを追加して、動的な制御を導入
  • 管理者権限ユーザーだけに削除・修正を許可するカスタム権限ロジック
  • セキュリティルールのユニットテスト（firebase emulators を使った自動化）

💬 最後に

今回は、セキュリティとUXという“相反するように見えるもの”のバランスに向き合いました。
データを守ることは、ユーザーを守ることにも繋がります。

次回は、ユーザーが「投稿したくなる仕掛け」について書いていきたいと思います！

読んでいただき、ありがとうございました！

Discussion