今年1月、「Moltbook」というSNSが公開されました。
AIエージェントだけが投稿できるという変わったSNSで、作ったのもほぼAI。いわゆるバイブコーディングです。
公開から3日以内に、セキュリティ研究者がこう気づきます。
「このアプリ、データベースの中身が誰でも読めるし、書き換えられる」
漏れていたのは、認証トークン約150万件、メールアドレス約3.5万件、非公開のメッセージ数千件。
運営はすぐ直しましたが、それまでの数日間は誰でも取り放題でした。
僕はAIツールの内製支援とセキュリティチェックを仕事にしています。
この事件、実は「AIで社内ツールを作った会社」で僕が一番よく見る穴とまったく同じでした。
何が起きたかと、そうならないために気をつけること5つを書きます。
====
何が起きたか
原因は、たった2つです。
1つ目。データベースに「自分のデータしか見られない」というルールが入っていなかった。
2つ目。データベースにつなぐための鍵が、ブラウザ側のコードにそのまま書いてあった。
ブラウザに書いてある鍵は、開発者ツールを開けば誰でも見えます。
その鍵でデータベースにつなぐと、ルールがないので全員分のデータが返ってくる。
つまり、アプリの画面を通さなくても、裏口から全部見えていたということです。
AIは「動くアプリ」はちゃんと作りました。
でも「他人には見せない」という部分は、頼まれてないので作らなかった。
ここがAIで作る時の一番の落とし穴です。
====
1. 「ログインできる」と「他人のが見えない」は別物
アプリを開発する際、ログイン機能はほぼ必ず付いてきます。
「とりあえずログイン機能つけたから大丈夫」と思いがちなんですが、これが違います。
ログインは「誰か」を確認する機能。
「その人が何を見ていいか」は、別に作らないといけない。
Moltbookも、ログイン自体はありました。
でもログインした後に、他人のデータに手が届いてしまった。
チェックは簡単です。
テスト用のアカウントを2つ作って、Aでログインした状態でBのデータのURLを直接開いてみる。
見えたらアウトです。
AIへの指示はこれです。
「ユーザーは自分のデータにしかアクセスできないようにして。他人のデータのURLを開いても見えないようにして」
====
2. データベース側にも「自分の分しか見えない」ルールを入れる
1番はアプリ側の話でした。
でもMoltbookのように、アプリを通さず裏口からデータベースに直接つながれることがあります。
なので、データベース自体に「この人はこの行しか見えない」というルールを入れておく。
これがあると、鍵が漏れても他人の分は取れません。
最近のAI開発でよく使われるデータベースサービスは、この機能を持っています。
ただし初期設定ではオフのことが多い。AIも頼まれないと入れません。
指示はこれです。
「データベースの全テーブルで、自分の行しか読めないルールを有効にして」
====
3. ブラウザ側に鍵を置かない
Moltbookのもう一つの原因が、鍵がブラウザに書いてあったことです。
アプリには「サーバー側で動くコード」と「ブラウザ側で動くコード」があります。
ブラウザ側は、利用者のPCに丸ごと送られる。つまり、そこに書いた鍵は全員に配っているのと同じです。
見分け方は、開発者ツールを開いて「key」「token」「secret」で検索してみる。
それっぽい長い文字列が出てきたら要注意です。
指示はこれです。
「鍵やパスワードはサーバー側だけに置いて。ブラウザ側のコードには絶対に含めないで」
====
4. 公開前に「別のAI」に悪い人役をやらせる
作ったAIに「安全？」と聞いても、「はい」と答えます。自分で作ったので。
なので、開発に使ったのとは別のAIに、攻撃者の目線でレビューさせます。
「このアプリに侵入するとしたら、どこから入る？」と聞く。
僕がクライアントのツールでこれをやると、気づけない穴がゴリゴリ出てきます。
Moltbookの2つの穴も、この質問で普通に見つかるレベルです。
指示はこれです。
「あなたは攻撃者です。このアプリで他人のデータを見る方法を全部挙げて。見つけたら直し方も出して」
====
5. 公開したら「誰が何を見たか」を記録して、最初の1週間は毎日見る
Moltbookは、外部の研究者が見つけて連絡したから直りました。
自分たちでは気づいていなかった。
社内ツールでは、誰も連絡してくれません。
だから、「誰がいつログインして、何のデータを見たか」を記録に残しておく。
そして公開後の1週間は、その記録を毎日見る。
知らないアクセス元、深夜の大量アクセス、1人が全員分のデータを開いている。
こういうのは、記録を見ればすぐ分かります。
指示はこれです。
「誰がいつ何のデータにアクセスしたか、記録を残して。ただし記録の中にパスワードや個人情報は書かないで」
====
まとめ
Moltbookの事件を1行にすると、
「AIは頼まれたものは作るけど、頼まれてないものは作らない」です。
社内ツールを作る時、僕らは「こういう機能が欲しい」は伝えます。
でも「他人には見せないで」「鍵はブラウザに置かないで」とは、言わない。
言わないから、入らない。
逆に言えば、この5つは全部、AIに一言足すだけで入ります。
まずは今動いているツールで、テストアカウントを2つ作って、他人のデータのURLを開いてみてください。
それだけで、Moltbookと同じ穴があるか分かります。
====
最後に一つ告知です。
弊社では、業務特化のAIエージェントを御社用にゼロから開発するサービスを提供しています。
研修やツール紹介ではなく、実際の業務フローをヒアリングして「明日から使えるもの」をそのままお渡しする形です。導入後の改善・内製化まで一貫してサポートします。
また、内製AIツールのセキュリティ・運用チェックと、その先の保守・改修までをエンジニアが伴走する形でも提供しています。作って終わりではなく、この記事の5つのような観点で「守り続ける体制」まで含めて整えるのが特徴です。
「うちのツール、他人のデータのURL開いたら見えるかも」と思った経営者・現場責任者の方は、ぜひ一度お話させてください。
初回ヒアリングは無料で、この記事で紹介した攻撃者目線のチェックのデモもその場でお見せしています。自分のシステムのどこが危ないかを一緒に整理するところから始められるので、お気軽にDMかLINEからご連絡ください。
「AI」と一言だけで大丈夫です↓
