セキュリティ · モバイル・クラウド診断

Firebase の落とし穴

Firestore風のREST APIを自作モックで再現し、セキュリティルールの緩さが何を許してしまうかを確かめます。

実習

localhost で実習

環境構築

★★★重さ 1 / 3

前提

sec-authz(認可の考え方)

倫理

第0章の法と倫理ゲートへの同意が必須です。

続きから

章の一覧

1. 未完了第0章はじめに — 守るのは、鍵ではなくルールFirebaseのようなクライアント直結型データベースでは、クライアントの鍵の秘匿ではなく、サーバ側のセキュリティルールが守りの要だと理解します。自作モックで学ぶ理由と、法と倫理ゲートを確認します。約6分次はここ
2. 未完了第1章開いたルール — 認証なしで、読み書きするFirestore風のREST APIを模したモックサーバに、セキュリティルールを開けたまま(誰でも読み書き可)公開し、認証なしで他人のデータを読み・書き換えます。約11分次はここ
3. 未完了第2章ルールを締める — 認証と所有者を要求する認証情報と所有者一致を要求するルールに直し、同じ攻撃が拒否されることを再検証します。本物のFirestoreルール構文との対応と、既定拒否の原則を確認します。約9分次はここ
4. 未完了第3章まとめ — BaaSでも、認可の原則は変わらないクライアントキーとセキュリティルールの区別、開いたルールの危険と締め方を畳みます。T6(モバイル・クラウド診断)の完成を確認し、道3全体を振り返ります。約4分次はここ

詰まったときはお助けページへ。章ごとのファイル一式をダウンロードして、途中から再開できます。