今回は、セクション５(セキュリティ編)のPart.１の記事になっています。
個人開発を行ってアプリケーションを作ったものの「セキュリティ」が気になる。
「誰かに乗っ取られてはしまわないだろうか？」
「利用料はいくらになるのだろうか？」
と思っている読者の方に私が行っているセキュリティ向上策を記事にしたものです。
実際に、Firebase Firestore DB(データベース）のセキュリティルールと内容（バリデーション）を実装してセキュリティを整えた内容になっています。
前回は、セクション４(UI/UX編)をお届けしてきました。
前回までの概要：
- セクション１：動くプロトタイプ作成：MVPを目指して動くwebアプリを作成。
- セクション２：欲しい機能の調整：Authや日本語化などの機能を追加。
- セクション３：バックエンド機能の実装：必要なFirebase機能(Remote Configなど）を実装。
- セクション４：UI/UXの調整：アプリの世界観や目標に沿った調整。
今回やる事：セクション５（セキュリティの向上ロードマップ）
アプリのセキュリティの向上
- Part1：Firestore DB セキュリティルールの内容変更。
- Part2：API Key Restrictions。GCPでのHTTPリファラーとAPI制限を設ける。
- Part3：環境変数の整理 (.env)。プロジェクト内APIの整理。
- Part4：予算アラートの設定。GCPで行う、もしもの備え。
それでは、セクション５(Part1)から始めていきます。
Firestore セキュリティルール（データの玄関）
Firestore DBは、Firebase機能のデータベースの役割を持っています。
そして私の開発中の「時計ログアプリ」の集めたログを保管する役割を担っている状態です。
現状、開発中の段階では、私だけしか扱うことはないので「すべて許可」にしている状態です。
しかし、このままでは「誰でも他人のデータを全削除・改ざんできてしまう。」鍵のかかっていない家の玄関を提供しているとても危険なセキュリティ状態になっています。
これを第一に対策して「個々の自分のデータしか読み書きできない」オートロック付きマンション。
住人（Auth認証済み）しか入れず、さらに自分の部屋の鍵しか開かないルールを追加していきます。
- プロジェクトコンソールでfirebaseと接続する。
- firebase loginで自身のFirebaseに許可を与える
- firebase initで初期化設定を行いファイルを作る。
- firebase deployで動作確認をする。
- AIエージェントにルール変更の依頼
- 4と同じfirebase deployでFirestore ルールが更新されているか確認。
流れの説明：Firebaseとの連携が必要な理由
ステップ１：１～４の準備手順で事前にエラーを回避する。
Firebaseにコンソールからログインして連携用のファイルを作成する準備が必要になります（1~4)。
※すでにログイン・連携している方はスキップしてください。
先にFirebaseと連携する必要：
メリット: ローカルのファイルが「正」となるため、Gitで管理でき、チーム開発やバックアップにもなります。
これを行うと: 数秒でクラウド上のルールが書き換わります。
次回以降もローカルファイルでFirestoreのルールを変更する事で(firebase deployコマンド)直ぐに変えることができます。
ステップ２：２ステップのシンプルな変更と確認をする。
その後、AIエージェントにFirestore セキュリティルールの変更を依頼して更新します。
よくある疑問
- ローカルファイル(
firestore.rules)を GitHub に上げたら、攻撃者に抜け道を見つけられませんか？ -
いいえ、ルールファイル自体は「秘密情報」ではありません。
セキュリティルールは「鍵」そのものではなく、「鍵穴の仕組み（ロジック）」です。
たとえ「本人しか開けられない」という仕組みが世界中に公開されていても、攻撃者が「本人の認証情報（鍵）」を持っていなければ、突破することはできません。
- 間違ったルールを書いて、気づかずにデプロイしてしまったらどうなりますか？
-
確かにその瞬間はセキュリティが弱まりますが、Git管理していれば「秒で」戻せます。
これがファイルを
.gitignoreに隠さず、Gitで管理すべき最大の理由です。Gitに履歴があれば、コマンド一つで「1分前の安全な状態」に戻せます。
- 他の人が勝手にルールを書き換えてデプロイしたらどうなりますか？
-
コマンド(
firebase deploy) は、あなたの許可（認証）がないと実行できません。GitHub上のファイルを書き換えることはできても、それを Firebase のサーバーに反映（デプロイ）するには、あなたの Google アカウントの権限が必要です。
Firebase Login
プロジェクトのターミナルを開いて以下のコマンドを入力します。
firebase loginブラウザが開き、Googleアカウントのログインを求められます。許可して進んでください。
- Enable Gemini in Firebase features?(Firebaseの機能でGeminiを有効にしますか？)
- Allow Firebase to collect CLI and Emulator suite usage and error reporting inforemation?
(FirebaseがCLIやエミュレーターの利用状況やエラー報告情報を収集することを許可しますか？)
Yes/Noどちらでもログイン操作に影響する事はありません。
提示されるリンクをクリックすると、以下の画像のようなFirebaseサインインブラウザが開くので３ステップを進めて、３つ目のコードをコピーしてください。
「Enter Autherization code:」にコードをペーストします。
確認：もう一度コマンドを入力すると「すでにログインしている」旨が表示される。
firebase init
続いてfirebaseとの通信をするための初期化設定を行っていきます。
firebase init firestore --project <例:My-Firebase-comp/ここはあなたのGCP プロジェクト名>コマンドの説明：
今回は、Firestore: セキュリティルールをファイルで管理したいので必要な(firestore機能)だけを指定して行っていきます。※必要な機能の分だけ設定を作ればOKです。
–projectで自分のGCPでのプロジェクトを指定したのは、まずFirebase機能はGCPと紐づいている為Firebaseでプロジェクトを立てた時に一緒にGCPでも紐づいたプロジェクトが作成されます。
注意点：混乱を招く要因になりうるポイント
firebase initこのコードのみだと新たにプロジェクトを作成してしまい本来のプロジェクトとは違う所に紐づいてしまいます。
結果的に次のデプロイ時にエラーが発生してしまいます。
それを防ぐために事前に本来使いたいプロジェクトを指定しておく事で目をそらさないようにする事ができます。
成果物の内容：プロジェクトに生成される２つのファイル
結果: firebase.json（設計図）と .firebaserc（宛先）が生成されました。
1.initコマンドと該当のGCPプロジェクトを指定、入力する。2.initの設定でどのファイルが対象かを記入。
firebase deploy：Firestoreとの通信をする。
firebase deploy --only firestore:rulesこのコマンドを行って反映されるのかを確認テストします。
※ –onlyでは、デプロイしたい必要なファイルのみを指定します。
ここで何もエラーなく終了したら成功です。
後は、AIエージェントにFirestore ruleのセキュリティ要件を持ったプロンプトを依頼して、先ほどと同じようにdeployコマンドを送信するだけでプロジェクトファイルで作成したルールがFirebaseのFirestoreルールに反映されます。
AIエージェントに依頼
テストモードのままになっているFirestoreを、本番運用に耐える安全な状態へ移行するフェーズ。
目的
- ユーザーごとのデータを確実に守り、不正アクセスを防ぐこと。
やること
- 認証必須化：ログインしていないユーザーは一切アクセス不可。
- 所有者限定アクセス：
users/{userId}配下のデータは、本人（UID一致）のみ読み書き可能。 - データ検証（任意）：
ログ保存時に、カテゴリや数値型、文字数などの最低限のルールをチェック。
結果
- 他人のログは「見れない・書けない・消せない」状態に。
- Firestoreを安心して本番利用できる土台が完成。
4と同じfirebase deployでFirestore ルールが更新されているか確認。
Firebase Console > Firestore > ルールに移動して実際に変わっているか確認します！
自身のファイル(Firestore.rules)と同じ内容であれば成功です。
まとめ
お疲れさまでした。今回は、 セクション５（セキュリティ向上）のPart１：Firestoreルールを更新して自分だけの部屋を作る仕組みを作る。を行いました！
結果として、
【Firestore DBのルールが更新されて、以前の「誰でも入れる」から「自分だけの部屋」の状態に変わりました。】
今回行った事：
- 事前準備：Firebaseとの連携。
- プロジェクトファイルのFirestore ルールを書き換え。
- Firebase側に更新。
今回の学び：
今までFirebase機能を自分のプロジェクトにインストールして作成を行っていましたが、今回はFirebaseへプロジェクトの内容を反映させるシステムを行えたのは大きな発見になりました。
これは「購入」と「販売」の２つ違いがあると考えます。
お店(Firebase)に商品(Firestore DB)を買う(インストール）のが「購入」であり、
逆に商品をフォーマットに従って作って(Firestore.rules)、お店(Firebase)の棚(Firestore機能)に「販売」してもらう。
こんな関係をイメージしました。
つまり今まで「購入」していたが、今回は「販売」できたということです。
次回予告：Part2: API Key Restrictions | GCPでのHTTPリファラーとAPI制限を設ける。）
- クラウド(GCP)でのセキュリティ向上を記事にしていきます。
- URLとAPI制限を設定して相互補完したセキュリティを設定します。
- 実際にセキュリティが機能しているかも画像で示します。
最後に：
ここまで読んでいただきありがとうございました。
セキュリティは、個人開発していく上で学んでおきたいポイントだと思います。今回の記事で学びになったり気づきになったらとても嬉しく思います。
他にもセキュリティ対策について行っている事があればSNSやコメントで共有して欲しいです。
次回もお会いしましょう！
Tomoya
コメント