何を確かめたかったか
英語学習アプリ Words Admin（https://words-admin.web.app/）には、利用者が自分のレッスンの録音と資料の写真をアップロードし、あとで見直す機能があります。ファイルは Firebase の Cloud Storage に置いています。誰が何を読めて、誰が何を書けるかは、Storage の「セキュリティ規則」で決めます。
録音はその人のレッスンの声そのものです。この機能で守るべきことは、本人は自分の録音を読めて、本人以外は読めないことです。前者は使っていればすぐに分かります。後者は、普段の操作では誰も試しません。今回は、この「読めないこと」を実際に確かめることにしました。
規則の中にあった、まとめて許す1行
録音の機能を作っている途中（2026-10-14）で、規則の中に次の1行を見つけました。
allow read: if request.auth != null
意味は「ログインしている人なら読める」です。場所を限っていないので、置き場全体に効きます。
Storage の規則は和集合で判定されます。どれか1つの規則が許せば、その操作は許可されます。個別の場所に「本人だけ」と書いてあっても、このまとめの1行が同時に許してしまいます。つまりログインしていれば、他人の録音を読めたことになります。
ここで書けるのは「読める状態だった」までです。誰かのファイルが実際に読まれたかどうかは確かめていないので、この記事でもそうは書きません。
この形の怖いところは、個別の規則を読むと正しく見えることです。「本人だけ」の行を見て安心しても、ほかの1行が全部を開けているかもしれません。点検するときは、許可を出している行を全部挙げ、その合計を見る必要があります。
直し方：名前で挙げた場所だけに規則を書く
まとめて許す1行はやめました。代わりに、規則は名前で挙げた場所だけに書いています。
- 録音と写真の場所は、本人の利用者IDの下だけ読み書きできる形にしました（例:
lessons/{uid}/{lessonId}/audio/…、…/images/…）。 - 以前からある別の2つの場所（録音のフィードバックと、文字起こしのファイル）も、同じように利用者IDで絞りました。
名前を挙げていない場所には、どの規則も許可を出しません。つまり誰も読めません。後で新しい置き場を足すときは、その場所の規則を明示して書かない限り、開かないことになります。
同じ作業で確かめたもう1つのこと
写真が HEIC（iPhone の既定の形式）だと、表示できないブラウザがあります。そこでサーバ側で JPEG を作り、元のファイルも残すことにしました。実測では 3024×4032 の写真1枚で 1.0秒でした。変換できなかったときは、画面にそう表示します。表示用の形に変換しても元は消さないので、あとで変換方法を変えたくなっても、元から作り直せます。
負のテスト22件で何を試したか
直した後、ローカルの模擬環境で22件の検査を走らせました。中心は「負のテスト」です。これは、通ってしまったら失敗になる検査です。「本人は読める」を確かめる検査だけでは、全員が読める状態でも通ってしまいます。そこで「他人は読めない」「ログインしていない人は読めない」を、検査の側から実際に試しています。
| 対象 | 確かめたこと | 種類 |
|---|---|---|
| 録音・写真 | 本人は自分の録音を読める | 通る側の対照 |
| 録音・写真 | 他人は録音を読めない | 負 |
| 録音・写真 | ログインしていない人は読めない | 負 |
| 録音・写真 | 他人は録音を上書きできない | 負 |
| 録音・写真 | 他人は以前からある録音のフィードバックを読めない（これまで読めた所） | 負 |
| 録音・写真 | 名前を挙げていない場所は、本人でも読めない | 負 |
| レッスンの記録 | 本人は自分のレッスンと文字起こしを読める・題名を直せる・自分名義で作れる | 通る側 |
| レッスンの記録 | 他人・ログインしていない人は読めない | 負 |
| レッスンの記録 | 本人でも、文字起こし・質問の履歴・解説は書き換えられない（サーバの関数だけが書く） | 負 |
| レッスンの記録 | 他人名義では作れない／作るときに文字起こしを持ち込めない | 負 |
| レッスンの記録 | 他人の使用分数（1日の上限の記録）は読めない | 負 |
「名前を挙げていない場所は、本人でも読めない」は、まとめて許す1行が素通ししていないことの確認です。「本人でも書き換えられない」は、利用者が自分で文字起こしや解説を差し替えられないことの確認です。読めるかどうかとは別の向きの制限なので、分けて試しています。
直しを外すと、検査は落ちるか
検査が全部通っても、それだけでは足りません。直す前の状態でも通る検査だったなら、その検査は今回の穴を何も見張っていないからです。
そこで、規則を古い形に戻して同じ検査を走らせました。結果は3件が落ちました。直しを外すと検査が赤くなるので、この検査は今回の穴を実際に見張っています。次に誰かが規則に広い1行を足しても、検査がそれを止めます。
ここでの判断の順番をまとめます。
- 規則を、許可を出す行の和集合として読む
- 直す
- 「読めないこと」を負のテストで試す
- 直しを外して、検査が落ちることを確かめる
4番目を省くと、検査があっても安心してよいかが分かりません。
業務に置き換えると
書類・音声・写真をアップロードさせる業務ツールを持っているなら、次の点を確かめておくと、今回と同じ形の穴を見つけられます。
- 規則を「許す方の和集合」として読んでいるか。 置き場全体をまとめて許す1行が1つでもあれば、個別の制限は効きません。
- 「本人は読める」だけでなく、「他人は読めない」「ログインしていない人は読めない」を検査で実際に試しているか。 通る側だけの検査では、全員に開いていても気づけません。
- 名前を挙げていない場所が閉じているか。 新しい置き場を足したとき、規則を書くまでは誰も読めない形になっているかを見ます。
- 検査を書いたら、直しを外して落ちることを確かめたか。 直しを外しても通る検査は、何も守っていません。
- 形式を変換しても、元のファイルを残しているか。 表示用に変換した後も、元から作り直せるようにしておきます。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。