はじめに — 守るのは、鍵ではなくルール

自分でサーバを書かなくてよいのは、とても便利です。でも、これまで「サーバが確認していたこと」——sec-authz の所有者チェック、sec-web-basics の認可——は、誰が代わりに確認するのか。答えは、セキュリティルールという、データベース側に書く条件式です。
Firestore なら、こんな形です(構文はイメージです)。

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

これが、事実上の「認可コード」です。アプリにサーバがなくても、この一行が sec-authz で見た「所有者チェック」の役割を担います。

Firebase のプロジェクトを設定すると、apiKey を含む設定情報をアプリに埋め込みます。ここで、sec-mobile で学んだ「秘密はバイナリに焼き込まない」を思い出して、「このapiKeyを隠さなきゃ」と身構える人がいます。でも、それは誤解です。
Firebase の apiKey は、sec-mobile で見た sk_live_… のような秘密鍵とは、性質が違います。「どのプロジェクトに繋ぐか」を示す識別子であって、これ単体で他人のデータを読み書きできる万能鍵ではありません。公式ドキュメントでも、クライアントに埋め込まれる前提の値だと説明されています。本当に守るべきは、鍵の秘匿ではなく、セキュリティルールの中身です。この区別を取り違えると、「鍵を一生懸命隠したのに、ルールが if true だった」という、本末転倒な事故が起きます。

実際の Firebase プロジェクトを持っていなくても、このコースは進められます。Firestore の REST API と同じ考え方(「認証情報を添えて、コレクション/ドキュメントのパスにアクセスする」)を、あなた自身の 127.0.0.1 に、node で再現します(法と倫理)。実際の JSON の細部は簡略化していますが、「ルールが緩いと何が起きるか」という核心は、本物とまったく同じです。