個人開発のSaaSをlaunchする前に、絶対やるべきセキュリティチェック5つ！Supabaseの脆弱性を実例で解説

外資系SEOスペシャリスト

Takuma Oka (岡 拓馬)

こんにちは、岡 拓馬（おか たくま）です。
このブログでは、海外ノマド×SEO×ストック収入をテーマに、自分の経験や学びを発信しています。

高校卒業後は料理人としてスタートし、その後、航空自衛隊での勤務を経て、2016年からWebライター・SEOコンサルタントとして独立。現在は、海外の外資系企業と契約しながら、フルリモートで働いています。拠点はアジア各国を転々としており、最近はベトナムやタイ、マレーシア、フィリピンなどでノマド生活をしています。

執筆者

こんにちは、岡 拓馬（@OkaTakuma1）です。

Web のSEO診断とAI検索（GEO/LLMO）対応をまとめて診断できる無料ツール「SEGO」を、個人で開発しています。4月30日の launch を目指して、ここ数ヶ月ずっとコードを書いてきました。

朝、launch 7日前のセキュリティ確認をしていたのですが、正直に言うと、致命的な脆弱性を1つ、ヒヤッとするものを2つ、見つけてしまいました。

この記事では、私が今朝発見・修正した3つの脆弱性と、その過程で得た「個人開発者がlaunch前に絶対やるべきセキュリティチェック5つ」をまとめます。

技術的な話も出てきますが、なるべくエンジニアでない方でも読めるように書きました。SaaSを使っている経営者の方、Web担当者の方にも関係がある話なので、ぜひ最後まで読んでみてください。

＼ あなたのサイトを診断してみよう！ ／

「Moltbook事件」を覚えていますか？

技術系のニュースを追っている方なら聞いたことがあるかもしれません。

2026年2月、AIエージェント専用ソーシャルネットワーク「Moltbook」で、150万件のAPIキーと3.5万件のメールアドレスが流出する事件が起きました。

原因は、データベースの設定の たった一行のミス でした。

「うちは大企業じゃないから関係ない」「自分が使っているSaaSは大丈夫だろう」と思った方こそ、ぜひ読み進めてみてください。

何が起きていたのか

Moltbook は、AIエージェントが投稿・コメント・投票を行うソーシャルネットワークでした。launch直後にバズり、わずか数日で「150万人のユーザー」を抱えるサービスとして話題になっていました。

ところが、サイバーセキュリティ企業 Wiz の調査で、ブラウザの開発者ツールから数行のコードを実行するだけで、データベース全体への読み書きが可能な状態になっていたことが判明します。

技術的に説明すると、データベース（Supabase という今流行のサービスを使っていました）の「行レベルセキュリティ（RLS）」という設定が、適切に行われていなかったのです。

これは、ものすごく簡単に言うと…

すべてのレコードに対して「誰でも読み書きしていいよ」と書いてある

という状態でした。

※ 参考リンク（一次ソースと日本語解説）
・Hacking Moltbook: AI Social Network Reveals 1.5M API Keys（Wiz Blog、英語、一次ソース）
・Moltbook、150万APIキー流出で露呈したAIエージェントの「致命的な三要素」（innovatopia、日本語解説）
・”人間は禁止”の新SNS「MoltBook」で情報流出か（サイバーセキュリティ総研、日本語まとめ）
・「1行もコードを書いてない」——3日後、150万APIキー漏洩（Zenn、個人開発者目線の検証記事）

なぜこれが起きるのか

Supabase は本当に便利なサービスです。データベース、認証、API がワンセットで提供されていて、個人開発者にとっては救世主のような存在です。

ただ、便利すぎるが故に、セキュリティ設定が「とりあえず動かす」ためのデフォルト状態のまま放置されがちという弱点があります。

特に、「公開する」と「非公開にする」を一行のSQL文で切り替えられるので、開発初期に「とりあえず公開設定」にして、その後修正を忘れる、というパターンが頻発します。

Moltbook の事件も、おそらくこの「設定し忘れ」が原因でした。

創業者自身が「コードは1行も書いていない、AIに作らせた」と公言していたことから、AIに任せた結果セキュリティ設定がそのまま放置されたとも言われています（vibe coding問題）。

SEGO で見つけた3つの脆弱性

今朝、私が SEGO で見つけた脆弱性は3つです。

順に解説していきます。

脆弱性① Supabase RLS の致命的な設定漏れ

まず、最も深刻だった1つ目から。

何が起きていたか

SEGO は、URLを入れるとSEOとAI検索の状況を診断するツールです。診断結果は「結果ページのURL（例: sego.jp/r/abc123）」で他の人と共有できる仕組みです。

つまり、「結果ページのIDを知っている人だけが、その結果を見られる」という設計です。

朝、Supabase の管理画面でデータベースの設定を確認していたところ、ある画面に目を疑いました。

diagnoses というテーブルに、こんな設定がありました。

Diagnoses are publicly readable (SELECT, USING: true)

訳すと

「診断データは誰でも読み放題ですよ」

これが意味することは、つまり…

SEGOで診断したことのある全企業・全個人のサイトURLとスコアが、APIキー1つ持っていれば誰でも全件取得できる状態だった

ということです。

なぜ致命的なのか

SEGO で診断する方の多くは、自分のサイトのSEO状態を知りたい、という目的で使われます。場合によっては「競合がどんなURL構造で運用しているか」を分析したい人もいます。

これらの情報が全件丸見えになるということは、たとえばこんなことが起きえます。

そして、コードを確認したところ、この脆弱性は「APIキーを持っている人なら誰でも」攻撃可能でした。

SEGOのAPIキーは、Webサイトのソースコードに公開されている性質のものなので、つまり全世界の人が攻撃可能な状態だったのです。

どう修正したか

修正方針は2段階です。

ステップ1: 「id を指定した1件取得」だけを許可する仕組みを作る

データベース内に「特定のidを指定した時だけ、その1件だけを返す」という関数を作りました。これを「RPC関数」と呼びます。

家のドアに例えると…

ステップ2: 既存の「誰でも読める」設定を削除する

データベース側の設定を厳格化しました。具体的には…

つまり「RPC関数経由でしか読めない、書き込みは可能、変更・削除は不可」という最小権限の設計にしました。

なお、この「.rpc() 経由で取得する」という方針は、過去にSupabaseで同様のインシデントを発見した方がベストプラクティスとして提唱されているものです。私も今回、その方針を踏襲しました。

参考: データベース丸見えのインシデント発見者になってしまった話。Supabaseをフロントエンドだけで実装する際はSELECTの扱いに注意！（Zenn）

攻撃テストで確認

修正後、自分で「攻撃者になりきって」テストしました。

ブラウザのDevToolsから、APIキーを使って以下を試しました。

結果は…

全部 401 Unauthorized でブロックされました。

そして、正規の方法（RPC関数経由）でアクセスした場合だけ、ちゃんとデータが取れることも確認しました。

学んだこと

Supabase（や、似た構造のサービス）を使う場合…

「とりあえず公開設定」のまま放置していないか、launch前に必ず確認する

これだけで防げる事故です。逆にこれを怠ると、launch直後に大事故を起こすことになります。

脆弱性② SSRF（サーバーサイドリクエストフォージェリ）

2つ目は SSRF と呼ばれる脆弱性です。

SSRF って何ですか？

タクシーに例えてみます。

SEGOは「お客さんが言った住所まで、こちらの社用車で走って情報を取ってくる」というサービスです。具体的には、お客さんが入力したURLにアクセスして、そのページの構造を解析します。

ところが、こんなお客さんが来たらどうなるでしょう?

「うちの会社のオフィスの中に、機密書類が置いてある金庫があるんですよ。そこまで運転して、金庫の中身を見てきてください」

普通のタクシーなら断りますが、プログラムは「言われた通り」に動いてしまうのです。

SEGOで起きえた攻撃

SSRF攻撃のパターンとして、こんなURLを入力されると問題でした。

入力URL（内容）	何が起きるか（結果）
http://localhost	サーバー自身の管理画面にアクセス
http://169.254.169.254/…	クラウドサービス（AWS等）の機密情報エンドポイント
http://192.168.1.1	内部ネットワークの管理画面
http://172.16-31.x.x	プライベートネットワークの内部通信

特に怖いのが2番目の 169.254.169.254 で、これは AWS や Google Cloud などのクラウドサービスの「サーバー自身の機密情報を取得できる特殊なアドレス」です。

過去には、Capital One という大手金融機関が SSRF を悪用されて、1億人分の個人情報が流出した事件もあります（2019年）。

SSRF攻撃で AWS のメタデータサービス（まさに 169.254.169.254）から認証情報を盗み取られた、という典型的なケースです。

参考リンク
・What We Can Learn from the Capital One Hack（Krebs on Security、英語、一次解析）
・Capital One Data Breach: What Happened, Impact, and Lessons（Huntress、英語、まとめ）

修正方法

入力URLを fetch する前に、「危険なアドレスではないか」を検証する関数を追加しました。

具体的には…

攻撃テスト結果

修正後、4種類の攻撃URLでテストしました。

すべて 400 Bad Request でブロックされました。

学んだこと

ユーザーが入力した URL を、何の検証もなくサーバーから fetch するのは危険

特に、診断ツール、URL短縮サービス、サムネイル生成サービスなど、「ユーザーのURLにアクセスする」性質のサービスは要注意です。

脆弱性③ Next.js のDoS脆弱性

3つ目は、自分が書いたコードではなく、使っているフレームワーク（Next.js）の脆弱性です。

npm audit で発見

npm audit というコマンドを実行すると、自分のプロジェクトが使っている全ライブラリに既知の脆弱性がないかをチェックしてくれます。

これを今朝実行したら…

next 13.0.0 - 15.5.14
Severity: high
Next.js has a Denial of Service with Server Components
fix available via `npm audit fix --force`

1 high severity vulnerability

High（高）レベルの脆弱性が1件見つかりました。

修正方法

幸いこの修正は1コマンドで終わりました。

npm install next@15.5.15

これでパッチが当たり、再度 npm audit を実行したら…

found 0 vulnerabilities

クリアになりました。

学んだこと

npm audit は週1で回そう

自分のコードに問題がなくても、使っているライブラリ側に脆弱性が見つかることは日常的にあります。npm audit で簡単にチェックできるので、習慣にすべきです。

個人開発者がlaunch前に絶対やるべきセキュリティチェック5つ

今朝の作業を経て、個人開発者向けのチェックリストにまとめます。SaaSをlaunchする前に、これだけは絶対にやってください。

データベースの権限設定（RLS）を見直す

Supabase, Firebase, その他のBaaSを使っている場合、全テーブルの「誰が・何を・できるか」をリストアップしてください。

特に「SELECT が USING (true)」になっているテーブルがないか。これがあったら、それは「誰でも全件取得可能」という意味です。

最低限、以下を満たしてください。

ユーザー入力URLは必ず検証する

ユーザーが入力した URL を、サーバーから fetch する場合、必ず以下のアドレスを拒否してください。

npm audit を週1で実行

自分のコードがどんなに完璧でも、ライブラリの脆弱性は防げません。

npm audit で High / Critical が出たら即修正。Moderate も無視せず確認。

env ファイルが GitHub に上がっていないか確認

git check-ignore -v .env .env.local .env.production

このコマンドで、すべての .env 系ファイルが .gitignore でマッチしていることを確認。

万が一、過去のコミットに含まれていたら、APIキーをすべてローテートしてください。

月額の利用上限を設定

外部API（OpenAI, Anthropic, Google Cloud, AWSなど）を使っている場合、コンソールで月額の利用上限を設定してください。

万が一、攻撃や設定ミスで暴走した場合の「最後のセーフティネット」になります。

たとえば、私は Anthropic Console で月 500 ドルの上限を設定しています。これがあるおかげで、最悪の場合でも被害は 500 ドルで止まります。

なぜこの記事を書いたのか

正直に言うと、今朝の発見は本当にヒヤッとしました。

3ヶ月かけて作ったサービスが、launch 7日前で「全データ漏洩可能」な状態だった。発見した瞬間、心臓が止まる思いでした。

ただ、この経験は、個人開発者全員に共有する価値があると感じました。

私が今朝発見した3つの脆弱性は、どれも「設定の見落とし」「ライブラリの更新忘れ」「入力検証の不足」という、個人開発で起きやすい典型的な失敗です。

そして、これらは launch前に確認すればすべて簡単に防げます。launch後に発見されると、ユーザーへの謝罪、データ流出の対応、信用失墜と、取り返しのつかない事態になります。

「自分には関係ない」と思っていた数時間前の自分に、伝えたいです。

SEGO（セゴ）について

最後に少しだけ、SEGO の紹介をさせてください。

SEGO は、URLを入れるだけで以下を診断できる無料ツールです。

「最近、Google検索の流入が減っているけど、AI検索ではどうなんだろう？」という疑問にお答えするツールです。

4月30日に正式 launch 予定です。今ならまだ無料で診断できます（その後も基本機能は無料を予定）。

▶︎segoでの無料診断はこちら↓

▶︎公式LINEでは無料でGEOチェックリストを配布中です！

おわりに

今朝の作業を振り返って、改めて「個人開発の難しさは、コードを書くこと以上に「正しく運用すること」にある」と痛感しました。

エンジニア1人で全てを背負う個人開発では、セキュリティチェックは後回しになりがちです。でも、後回しにした結果が Moltbook 事件のような大事故です。

この記事が、これから launch を控えている個人開発者の方の参考になれば嬉しいです。

何か質問やフィードバックがあれば、X（@OkaTakuma1）か LINE公式アカウントまで気軽にどうぞ。

▶︎セキュリティ + SEO の総合相談はこちら↓