【DAY100】Firebase × JavaScript生活アプリのセキュリティ改善
自作の生活管理アプリに「セキュリティ目線」を入れる
これまで100日間、生活ログを管理・可視化するWebアプリを Firebase と JavaScript で構築・改善してきた。
ただ、使い勝手やデザインばかりに目が行き、セキュリティ設計はほぼ後回しだったのが正直なところ。
最近になって、
「自分の生活ログとはいえ、外部に漏れたら嫌な情報もあるよな」
という危機感が少しずつ出てきた。
本記事では、生活ログアプリのセキュリティ改善について、現状・課題・対応策をまとめてみる。
現在のアーキテクチャとセキュリティの弱点
まず現在のアプリ構成は以下の通り：
- Firebase Authentication（Googleログイン）
- Cloud Firestore（ユーザーごとの生活ログ保存）
- Firebase Hosting（静的ホスティング）
- Vanilla JavaScript（クライアントロジック）
ログインは Firebase Auth に任せており、Firestore 側ではルールで「ユーザー本人のみアクセス可」にしている。
とはいえ、実際には以下のような脆弱なポイントが残っていた。
問題点
- Firestore セキュリティルールが曖昧（read/write を広めに許可していた）
- ログイン後の JWT（トークン）検証をクライアント任せにしていた
- クライアントから直接 Firestore にアクセスしているため、リクエストの検証が甘い
- データ入力時にバリデーションがなく、不正入力の温床になりかねない
セキュリティ改善に向けた対応
以下、優先度の高いものから順に改善を始めている。
1. Firestore セキュリティルールの強化
まずはここ。全ての読み書きに「request.auth.uid == resource.data.userId」のようなチェックを入れることで、他人のデータへの不正アクセスを防止。
また、書き込み時に createdAt や updatedAt をユーザーから渡させず、Cloud Functionsで自動付与するよう変更。
2. Cloud Functions 経由のデータ処理へ移行
今まではクライアント（JavaScript）から直接 Firestore に書き込みを行っていたが、Cloud Functions 経由に変更。
- リクエスト内容のサニタイズ
- 認証トークンの検証
- ログの保存・監査ログの記録
などをサーバー側で処理し、信頼できるコードだけがデータベースに触れられる構造にした。
3. フロントエンドでの入力バリデーション
生活ログの内容とはいえ、自由入力欄に悪意のあるスクリプトを埋め込まれると問題になる（XSSのリスク）。
そのため、入力値には HTML タグの除去、文字数制限、形式チェックなどを追加。
将来的なセキュリティ対策
今後は以下も視野に入れている：
- **監査ログ（Audit Log）**の導入 → いつ誰がどのデータにアクセスしたかを記録
- 役割ベースアクセス制御（RBAC） → 管理者／一般ユーザーなどに分けた制御
- APIキーの非公開化 → Firebase Config を dotenv 管理し、ビルド時に埋め込む形式へ
- OAuth連携の検証強化 → ソーシャルログインのトークン失効タイミングなどへの対処
終わりに
最初は「生活改善アプリを作ろう」くらいの軽いノリだったが、使い続けるうちに自分の生活ログ＝プライベートデータの重要性に気づいた。
便利さと引き換えに、セキュリティの甘さがリスクになりうることを痛感した。
Firebase は手軽な反面、適切な設計と設定がなければ、穴だらけのサービスになってしまう。
これからも「生活をコードで良くする」だけでなく、「安全に運用する」という視点を忘れず、改善を続けていく。
Discussion