お客様が頼りにする前に、Firebaseのセキュリティルールを正しく

よくある問題

何で作ったかにかかわらず、レビューが追いつかない速さで育ったアプリによく見られる問題です。ほとんどは、今の環境のまま直せます。

1. 開発中のままのルール

   すべての読み書きを許可するルールでは、データが開いたままになります。日付で期限が切れるルールは、その日が来るとすべての利用者を締め出し、それが本番で起きることもよくあります。

2. サインインしか確認しないルール

   サインインした利用者なら誰でも許可するルールでは、どのお客様もほかのお客様のデータを読めてしまいます。ルールで、各ドキュメントを見てよい人と結びつける必要があります。

3. 公開用のキーと、本当のシークレット

   FirebaseのWeb設定にあるapiKeyは、設計上公開されるものです。プロジェクトを識別するためのもので、守るためのものではありません。サービスアカウントキーなどの本当のシークレットは、ブラウザに配信したり、リポジトリに置いたりしてはいけません。

4. 呼び出し元を信用するCloud Functions

   Admin SDKを使う関数は、セキュリティルールを迂回します。そのため関数ごとに、呼び出し元が誰かを確認し、受け取った値を検証する必要があります。

5. ストレージのルール

   Cloud Storageには、データベースとは別のルールがあります。アップロードされたファイルにも、レコードと同じ注意が必要です。

6. 上限のない費用

   ループの中のクエリや、ほかの誰かに読まれている開いたままのコレクションは、請求額となって表れます。予算アラートとクエリの上限があれば、早めに気づけます。

Firebaseのアプリで監査が確認すること

コード・プロダクト監査では、外から見える部分だけでなくコードそのものを読み、すべての指摘を事業への影響で順位づけします。Firebaseのアプリの場合は、次の点を確認します。

• Firestore、Realtime Database、Cloud Storageのルール。誰が何を見るべきかと照らし合わせて確認します。
• 配信されるバンドルに含まれるキー。設計上公開されるものと、含まれてはいけないもの。
• 認証プロバイダー、サインアップ、メールアドレスの確認。
• Cloud Functions。誰が呼び出せるか、何を信用しているか。
• App Check、APIキーの制限、予算アラート。
• 環境、デプロイ、バックアップ。
• プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

公開中のアプリを1日で確認する、固定価格のローンチチェックもご用意しています。認証、RLS（行レベルセキュリティ）とデータアクセス、シークレットを確認し、リスクの大きいものから5件を30分のお打ち合わせでご説明します。 ローンチチェックについて

今の環境のまま、本番で通用する状態へ

基本のご提案は、Firebaseのまま堅牢にすることです。別のバックエンドへの移行は、監査でその費用に見合うとわかった場合にだけご提案します。

Firebaseのアプリを、まず無料チェックで

無料チェックは、配信されているJavaScriptに含まれるキー、ヘッダー、HTTPS、バージョンなど、アプリがすでに外に見せているものをスキャンし、2営業日以内にAaronが結果を確認します。メールでのご確認と、アプリの所有者であることの確認が済んでから実行します。