Tsumiki

コース目次 / 第3章

まとめ — BaaSでも、認可の原則は変わらない

クライアントキーとセキュリティルールの区別、開いたルールの危険と締め方を畳みます。T6(モバイル・クラウド診断)の完成を確認し、道3全体を振り返ります。

第3章 / 全4章目安 約4分この章のゴール: Firebase診断の要点を畳み、T6の完成と道3全体のつながりを確認する

サーバコードを書かない BaaS の世界でも、認可の原則は変わらない——これが、このコースの結論です。

Firebase診断・早見表

確認すること 誤解しやすい点
クライアントの設定キー(apiKey) 秘密ではない。隠す対象ではなく、識別子
セキュリティルール ここが本当の守りの要。既定拒否・認証必須・所有者一致を確認する
認証なしアクセス 拒否されるか(request.auth != null)
他人としてのアクセス 拒否されるか(request.auth.uid == 対象のID)

「鍵を隠す」ことと「ルールを締める」ことを混同しない。これが、このコースいちばんの持ち帰りです。sec-mobile で「秘密はバイナリに焼き込まない」と学んだ直後だからこそ、この対比が生きます——秘密にすべきもの(sk_live_のような鍵)と、公開されて構わないもの(Firebaseのapiキー)を、正しく見分ける。

T6(モバイル・クラウド診断)が、完成しました

sec-mobile でアプリ自体の静的解析を、このコースでバックエンド(BaaS)の設定確認を学びました。実際のモバイルアプリは、この両方が組み合わさって動いています——アプリのコードがどれだけ堅くても、バックエンドのルールが緩ければ、そこから漏れます。逆もまた然り。両方を見て、初めて「診断した」と言えます。

道3を、振り返って

T0(法と倫理)から始まり、T1(診断の土台)、T2(低レイヤー)、T3(Web診断)、T4(認証・認可)、T5(診断実務)、そしてT6(モバイル・クラウド)。扱う対象は、HTTPからメモリ、GraphQLからAPKまで、大きく広がりました。でも——「事実は正しい場所が持つ」「信じるものを明示する」「確認と実行の隙間を無くす」「多層防御」という、sec-securecodingで体系化した原則は、どの層でも、姿を変えて、同じように現れ続けました。

このコースの実習も、すべて自作のモックだけが相手でした(法と倫理)。実際のFirebaseプロジェクトを持つ日が来たら、この目で自分のルールを見直してみてください。

お疲れさまでした。次はT7、CTFという実戦の場で、この目を試すときです。

こうなっていればOK

この章で卒業です。

この章はまだ完了していません。