INSIGHT
非公開でも、基盤に欠陥があれば——Base44の認証問題から提供者へ確かめること
非公開設定だけでは、誰が入り、何をできるかは決まりません。Base44で修正された認証問題をもとに、提供者へ確かめる範囲と、自社で決める権限を分けます。
「社内だけで使うアプリです。検索にも出ません。だから公開して大丈夫ですよね」
その確認に、作成者が見られる画面やコードだけで答えるのは無理があります。利用者登録やログインを共通基盤が担っているなら、その内側には利用者から見えない部分があるからです。
だからといって、基盤に欠陥が見つかった事例を、そのまま「情報が盗まれた」「作った人が間違えた」と読むのも正確ではありません。修正済みの脆弱性と実際の被害を分け、利用者と提供者の責任をつなぐことが、次の打ち合わせで必要な仕事です。
1. 「非公開」を、三つの問いに分けます
非公開設定は、一覧や検索結果に表示しないための設定かもしれません。しかし、「見つかりにくい」と「許可のない人が入れない」は別です。
認証は、アクセスしている人が誰かを確かめる仕組みです。認可は、その人がどの情報を読み、どの操作を実行してよいかを決める仕組みです。公開範囲、認証、認可は、それぞれ別の問いとして確認します。
たとえば、リンクを知っていても利用者登録はできないか。退職した人はログインできないか。営業担当者が別部署の顧客情報を読めないか。管理者でない人が利用者を追加できないか。普通にログインできた一例だけでは、これらの境界は確かめられません。
「非公開」は入口の呼び名です。誰が入り、入った人が何をできるかは、別に確かめます。
2. 見える範囲が違うから、責任も分けます
利用者側は、アプリの用途、扱う情報、招待する人、管理者、退職・異動時の権限変更を決めます。誰に何をさせるかを決めないままでは、基盤が正しく動いていても、広すぎる権限や残ったアカウントによる問題は防げません。
提供者側には、共通のログイン機能、利用者登録の経路、基盤の更新、脆弱性の修正など、利用者が直接変更できない領域があります。どこまでを提供者が担い、どこからが各アプリの設定なのか。重要な修正をどう通知し、利用中の環境へいつ反映するのか。ここは提供者の資料や窓口で確かめます。
OWASPのAuthorization Cheat Sheet は、必要最小限の権限、初期状態では許可しない考え方、リクエストごとの認可確認を扱っています。特定サービスやAI固有の説明ではありませんが、利用者側の設定と提供者側の実装を切り分けて質問するための基準になります。
3. Base44の報告は「修正された脆弱性」です
2025年7月29日、セキュリティ企業Wizは、Base44の非公開アプリで、許可されていない利用者の登録とアクセスにつながる認証回避を実証したと報告しました 。Wizによると、問題は各アプリの生成コードではなく共通基盤側にあり、複数の内部アプリへ影響する可能性がありました。
同じ報告には、その後の経過も書かれています。提供側は通知から24時間以内に修正し、Wizは2025年7月10日に修正を確認しました。Wixは、調査時点で過去の悪用や顧客への影響を示す証拠はなかったと説明しています。
脆弱性は、攻撃や誤操作につながり得る弱点です。弱点が実証されたことと、その弱点が悪用され、情報流出などの被害が発生したことは同じではありません。
この事例で確認されたのは、基盤側の認証回避と、その修正です。顧客データの窃取や利用者の過失が確認された事例として扱ってはいけません。
この区別は、危険を小さく見せるためではありません。原因と時点を正しく分けなければ、修正を確認すべき相手も、自社で直すべき設定も取り違えるからです。
4. 「安全ですか」では、判断に使える答えを得られません
提供者へは、具体的に尋ねます。
- 認証と認可のうち、共通基盤が担う範囲はどこか。
- 重要な脆弱性の通知を、誰が、どの経路で受け取れるか。
- 修正が自社の利用環境へ反映されたことを、どこで確認できるか。
- 利用者登録、外部公開、管理者権限を制限する設定は何か。
- 異常が疑われるとき、停止と調査を依頼する窓口はどこか。
社内では、招待できる人、載せてよい情報、管理者、アカウント棚卸しの時期、異常時に利用停止を決める人を合意します。提供者が共通基盤を修正しても、自社の不要なアカウントや広すぎる管理者権限までは整理されません。反対に、利用者がコードを点検しても、共通基盤の内部実装を保証することはできません。
作成者、業務責任者、情報システム担当が、同じ確認表を見られるようにします。「提供者の回答待ち」と「社内で未決定」を分ければ、誰か一人へ責任を集めずに判断を前へ進められます。
提供者の内部実装をすべて開示してもらう、という要求ではありません。公開された仕様、契約上の担当範囲、管理画面の設定、通知の仕組みを組み合わせ、自社で判断に使える証拠をそろえます。回答が得られない重要な項目は「対応しているはず」で埋めず、その情報を載せない、対象用途を保留するなど、利用範囲の判断へ戻します。
5. 修正確認を、一度きりの安心で終わらせない
基盤は更新され、アプリの使い方も変わります。新しい外部連携を加えたとき、管理者を増やしたとき、機密性の高い情報を扱い始めたときは、最初の回答がどこまで有効かを見直します。
提供者から重要な通知が出たら、影響するアプリ、利用者、データ、管理者を特定する。利用者から「見えてはいけない情報が見える」と連絡が来たら、一時停止する人、提供者へ連絡する人、社内へ報告する人を決めておく。必要なのは、利用者が基盤の欠陥を自力で発見することではなく、異常を適切な確認先へ届けられることです。
責任分担とは、責任を押しつけ合う境界線ではありません。見える人が確認し、その結果を同じ業務判断へ戻す流れです。
基盤の認証は提供者へ、自社の権限とデータは社内へ確かめる
非公開アプリの安全性は、作成者の点検だけでも、提供者の「対応済み」という説明だけでも決まりません。
修正済みの脆弱性は、修正済みとして読む。被害が確認されていないなら、被害事例に変えない。そのうえで、基盤が担う認証は提供者へ、自社の利用者・権限・データは社内へ確かめます。責任の所在を正しく分けることが、誰かを責めずに弱点へ対処し、使い続けるための土台になります。