GRADUATION
「守るのは鍵ではなくルール」だと、体で理解しました。
Firebaseのクライアント設定キーが秘密ではないという、よくある誤解を解き、自作モックでセキュリティルールの緩さ(認証なしの読み書き)が何を許すかを確かめました。実案件で最も多い所見の一つを、仕組みから理解しました。
おつかれさまでした。
持ち帰るもの
- クライアントキーは、秘密ではないFirebaseの設定キーは「どのプロジェクトか」を示す識別子で、公開される前提です。守るのはキーの秘匿ではなく、サーバ側のセキュリティルールです。
- 既定は拒否、ルールで明示的に許可allow read, write; if true は「誰でも」を意味します。認証済みかつ本人であることを、ルールの条件式で明示的に要求します。
- バックエンドが無くても、認可は要るサーバコードを書かないBaaS(Backend as a Service)の世界でも、認可の原則(事実はサーバ=ルールエンジンが持つ)は変わりません。
次にやるといいこと
- 実際のFirebaseプロジェクトを持っていれば、Firebase CLIのエミュレータ(firebase emulators:start)で、ここで学んだ確認を本物のルールに対して行えます。
- このコースで見た「クライアントの鍵は秘密でない」という区別は、sec-mobileで見た「APIキーは秘密にする」との対比として、あわせて覚えておくと実務で迷いません。