Bubbleでデータが見えてしまう事故を防ぐ：プライバシールールの確認

画面で隠すだけでは足りない理由

画面の要素を「表示しない」にしても、そのページがデータを読み込んでいれば、データ自体は端末側に送られている可能性があります。守る場所は画面ではなく、データを返す側です。

プライバシールールは加算式です。公式の説明では、複数のルールがある場合、どれか1つでもアクセスを許可すれば、そのユーザーはデータを見られます(Privacy)。つまり、厳しいルールを足しても、緩いルールが残っていれば意味がありません。点検では「いちばん緩いルール」を探すのがコツです。

設定画面で見る権限の意味

Dataタブの「Privacy」で、データタイプごとにルールを開きます。ルールは「When(条件)」と「権限」の組です。公式ページに載っている主な権限は次のとおりです(Privacy、Data API privacy rules)。

• View all fields、意味：そのデータの項目を見られるか(項目を選ぶこともできます)、点検の観点：見せる項目だけに絞れているか
• Find this in searches、意味：「Do a search for」で一覧として見つけられるか、点検の観点：他人の分まで検索で取れないか
• Constrainable fields、意味：検索の絞り込み条件に使えるか、点検の観点：見せない項目を条件に使えないか
• View attached files、意味：保存したファイルを取得できるか、点検の観点：添付ファイルの扱いが本体と揃っているか
• Allow auto-binding、意味：入力欄との自動連動での更新を許すか、点検の観点：他人のデータを書き換えられないか
• Create/Modify/Delete via API、意味：Data API経由の作成・変更・削除、点検の観点：不要なら無効のままか(初期状態ではオフ)

「Everyone else」のルールは特に重要です。セキュリティ診断の説明では、このルールで「View all fields」が有効だと、より制限的なルールがあっても機密項目が誰にでも見える状態として検出されるとされています(Security issue details)。

新しいデータタイプは、作成時に「private」を選ぶと作成者だけが閲覧できるルールが付きます。「public」を選ぶと全員に見える状態になります。初期設定は作成時の選択によるため、自分のアプリでPrivacyタブのチェック状態を確認してください(Data tab)。

データタイプ別の点検チェックリスト

次の表は、予約管理アプリを想定した説明用の例です。実際の操作画面で検証した結果ではありません。自分のデータタイプ名に置き換えて使ってください。

• User、本来見られる人：本人。管理者は必要な項目だけ、確認すること：メールアドレス、電話番号などを「本人のみ」にしたか。他人に見せる項目(表示名など)は別に絞ったか、危ない状態の例：Everyone elseで全項目が見える
• Booking(予約)、本来見られる人：予約した本人と管理者、確認すること：Whenが「Booking's Creator is Current User」などになっているか。Find this in searchesが全員に開いていないか、危ない状態の例：ログアウト状態でも予約一覧を検索できる
• Message(メッセージ)、本来見られる人：送信者と受信者だけ、確認すること：送信者・受信者のどちらかを条件にしているか、危ない状態の例：条件が空、または常に「はい」になる式
• Menu(公開メニュー)、本来見られる人：全員(公開してよい情報だけ)、確認すること：公開してよい項目だけを全員に許可しているか。原価など内部項目が同じタイプに混ざっていないか、危ない状態の例：内部メモの項目まで全員に開いている
• Setting(管理設定)、本来見られる人：管理者のみ、確認すること：Everyone elseの権限が全部オフか、危ない状態の例：通知先メールなどが全員に見える

見落としやすい3点

• 条件式が常に真になる:Whenに入れた式が空の値と比較されると、意図せず全員に当てはまる場合があります。セキュリティ診断の説明でも、常に真になるルールや空の項目の扱いが公開の原因として挙げられています(Security issue details)。
• 検索で値を推測される:項目を見せない設定でも、その項目で絞り込めると、検索を重ねて中身を推測できる場合があります。診断では、「Find this in searches」が有効で、項目の表示が無効、検索条件への使用が有効な組み合わせが検出対象です。
• 1つのデータタイプに公開用と非公開用の項目が同居する:権限は項目単位で分けられますが、設定ミスが怖い場合は、公開情報と内部情報を別のデータタイプに分けるほうが点検しやすくなります。これは公式の要件ではなく、編集上の提案です。

手順:設定を見直して、実際に確かめる

1. 一覧を作る:Dataタブでデータタイプと項目を書き出し、「公開してよい」「本人だけ」「管理者だけ」に分類します。
2. 各ルールを開く:Privacyタブでデータタイプごとに、ルール名、When、チェックの付いた権限を確認します。
3. Everyone elseを最初に見る:View all fields、Find this in searches、View attached filesのチェックを確認します。公開データ以外は原則オフにします。
4. 本来の人にだけ許可するルールを足す:例として「Booking's Creator is Current User」のように、条件で本人を指定します。
5. 動作を確かめる:Dataタブの「Run as」で特定ユーザーとして動かせます。プライバシールールによる表示を確かめるには、別アカウントでログインした状態とログアウト状態の両方でも画面を確認してください。「Run as」中はログアウトするまでそのユーザーとして動くため、データを変更しないよう注意が必要です(Data tab)。
6. セキュリティ診断を見る:ルール未設定、機密項目の公開、検索プライバシーが「Strict」でない場合などが指摘されます(Security issue details)。診断は点検の補助であり、合格しても安全の保証にはなりません。
7. Data APIを使うなら別途確認する:APIの権限はデータ取得のクライアントにだけ適用されます。APIトークンで認証した場合は管理者権限になり、プライバシールールが無視されるとの記載があります(Data API privacy rules)。トークンは公開しないでください。

AIにルールの点検を手伝ってもらう

AIはBubbleの画面を直接見られません。設定内容をテキストで渡し、見落としの指摘を頼む使い方になります。実名やメールアドレスなどの実データは貼らず、データタイプ名と設定の文字だけを渡してください。

Bubbleのプライバシールールを点検してください。
アプリ:予約管理(説明用の仮の内容です)
データタイプ:Booking
項目:日時、メニュー、お客様メモ、電話番号
ルール1 名前:本人
  When:Current User is logged in
  権限:View all fields=オン、Find this in searches=オン
Everyone else:View all fields=オフ、Find this in searches=オフ

お願い:
1. 他人の予約が見えてしまう可能性を、理由つきで挙げてください。
2. Whenの式の直し方を3案出してください。
3. 実機で確認するテスト手順を、ログアウト状態と別アカウントに分けて書いてください。

この例だと、ルール1の条件は「ログインしていること」だけで、予約の持ち主かどうかを見ていません。ログイン中のユーザー全員が全員分の予約を見られる可能性があります。AIの回答は、そこを指摘できるかが目安です。AIの提案は、必ず自分のアプリで試して確かめてください。公式の仕様と食い違う場合は、公式マニュアルを優先します。

公開前の最終確認

• 全データタイプで、Everyone elseの権限を意図して決めた。
• 本人だけの情報に、本人を指定するWhenがある。
• ログアウト状態で、保護したいデータが画面にも検索にも出ない。
• 別アカウントで、他人のデータが出ない。
• 開発版と本番版は別のデータベースなので、本番側でも同じ確認をした。
• Data APIを使う場合、トークンを共有しておらず、不要な作成・変更・削除を許可していない。

個人情報を扱うアプリでは、日本の個人情報保護法などの義務が関わることがあります。取り扱いの範囲は事業内容によって異なるため、迷う場合は個人情報保護委員会の案内や専門家に確認してください。