ログインできることと、他人のデータに触れないことは別です。確かめる方法は、アカウントを2つ作り、片方でログインしたまま、もう片方のデータを URL や ID で指定してみることです。見える、変えられる場合は、公開前に権限の制御（認可）を足してください。
ログインと、権限の制御は別のもの
ログインは「あなたは誰か」を確かめる仕組みです。それに対して、権限の制御（認可）は「あなたは、このデータに触れてよいか」を決める仕組みです。
AI にアプリを作らせると、ログイン画面はすぐできます。ログインした人にはデータが表示され、画面上は問題なく動きます。ところが、画面に出ないようにしていることと、データに触れられないようにしていることは別です。画面から他人のデータへのリンクを消しても、URL や ID を直接指定すれば開ける、という状態が起こります。
事例: Lovable 製アプリの RLS 不備（CVE-2025-48757）
2025年3月に、Lovable で生成されたサイトで、データベースのアクセス制御が不十分な例が見つかりました（発見は 3月20日）。Supabase の RLS（行単位のアクセス制御）が足りず、認証なしの第三者がデータベースを読み書きできた、と報告されています。発見者の説明では、調べた 1,645 件のプロジェクトのうち 170 件が該当しました。その後、CVE-2025-48757 として、2025年5月に公開されました（発見者の声明（新しいタブで開きます）、SentinelOne の脆弱性データベース（新しいタブで開きます））。
ここで大事なことがあります。この CVE には、**供給元の Lovable が異議を出している（disputed）**という注記が付いています。CVE の記述には、Lovable のプラットフォームを使う各顧客が、自分のアプリのデータを保護する責任を負う、という趣旨の説明があります。
私たちは、この事例を「Lovable は危険だ」という話としては読みません。どのツールで作っても、同じ論点が残るからです。データの保護は、最終的に、アプリを作って公開した側の責任になるということです。ツールが基本的な設定を助けてくれることはあっても、公開するアプリで他人のデータが守られているかを確かめる役目は、公開する人にあります。
私たちの考え方: 権限は「画面」ではなく「データ」の側で守る
確かめるべきことは、ログインできるかではなく、ログインした人が、自分のデータだけに触れられるかです。そして、それを守る場所は、画面ではなく、データを返すサーバーやデータベースの側です。
画面で隠すだけの対策は、直接 URL や API を呼ばれると破られます。サーバーやデータベースの側で「この人は、このデータに触れてよいか」を毎回確かめる。これが判断基準です。一般的には、データベース側で行単位のアクセス制御（RLS など）を設定する構成や、サーバー側で持ち主を確かめる構成があります。どちらを使うかは、アプリの作りで決まります。
確かめ方: アカウントを2つ作る
専門知識がなくてもできます。次の順で試してください。
- アカウントを2つ作る。 A と B とします。
- A でデータを作る。 注文、投稿、プロフィール、ファイルなど、アプリが扱うデータを作ります。そのデータの URL か ID を控えます。
- B でログインし直し、A のデータの URL を開く。 見えてしまったら、権限の制御がありません。
- ID を書き換えてみる。 URL の中の数字や文字列（
/orders/123の123など）を別の値に変えて開きます。他人のデータが見えたら同じです。 - 見るだけでなく、変更・削除もできるか試す。 B から A のデータを更新・削除できないかを確かめます。見えないだけで、変えられる状態もあります。
- ログアウトした状態でも試す。 ログインしていない人に、データが返ってこないかを確かめます。
- 管理者向けの画面を、一般アカウントで開く。 管理画面の URL を直接開き、一般アカウントで入れないかを確かめます。
どれか1つでも通ってしまえば、公開前に直す対象です。試した結果は、メモに残しておくと、直した後の再確認に使えます。
私たちの経験
私たちは、ログインはできるのに、他人のデータを見たり書き換えたりできる状態（認可がない状態）を見たことがあります。ログイン画面があると、作った人も使う人も「守られている」と感じやすい。そこに落とし穴があると感じています。
だからこそ、私たちは、権限は「ログインがあるか」ではなく、別のアカウントで実際に試して確かめることを勧めます。
公開前に確かめる4点（秘密情報・権限・復旧・保守）の全体像は、AIで作ったアプリを本番化するにはにまとめています。この記事は、その2点目を詳しく説明したものです。
wizgeek にできること
確かめて不安が残ったとき、または確かめ方に自信がないときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。