ユーザーが他人のデータを見られてしまう
誰かがログインして、自分のものではない一覧を見た — 他人の注文、他人のメッセージ。あるいはまだ起きていないが、その可能性にいま思い当たった。これを読むには後者のほうがよいタイミングです。
なぜ見えにくいのか
この種のアプリが抱える最も深刻な欠陥であり、同時に最も静かな欠陥です。行レベルセキュリティのポリシーが抜けていても、エラーは出ず、何も遅くならず、データが露出した本人からの問い合わせも来ません — ページは、誰にとっても、すべてを表示したまま、正常に動きます。
しかも、まっとうな経緯でそうなります。行レベルセキュリティはポリシーを書くまで既定で無効で、後から追加したテーブルはポリシーを引き継がず、自分のアカウントに対して書いたクエリは、利用者が自分だけのうちは正しく見えます。
Sixty は何をするのか
すべてのクエリを、ある特定の形について確認します。名前からして1人分のデータを持つテーブルであること、文のどこにも絞り込み条件がないこと — user_id も org_id も tenant_id も auth.uid() も — そして単一検索では説明のつかない行数が返っていること。この3つがすべて成り立たない限り、何も言いません。
成り立った場合、検出結果はクエリと操作を名指しし、侵害を断定するのではなく確認を求めます。データベース内部で適用されるポリシーは、アプリが送った文には現れません。つまりここで見つかるのは「RLS がなければ危険なクエリ」であり、それはまさに、RLS が抜けている可能性が最も高いときに確認すべきクエリです。
できないこと
見えるのは文だけでポリシーは見えないので、安全側に外すことがあります。ポリシーで正しく守られているクエリでも指摘されうる、ということです。また、誰のデータが露出したのかは分かりません — あなたのユーザーについて何も収集していないからで、それは導入しても同意バナーに何も足さずに済む理由と同じです。
OpenTelemetry
OpenTelemetry をすでに使っていますか？
現在の Collector と exporter はそのまま使えます。Sixty は接続された trace と有用な runtime metric を取り込み、release regression を推論します。対応する native agent があれば、function と DB driver の詳細がさらに得られます。