メインコンテンツへスキップ
AMPL
事故の9割は、3つの過ちから
レッスン 2 / 15|10分で読めます

事故の9割は、3つの過ちから

実際に起きた事故を3つ解剖する。RLS未設定・鍵の直書き・Gitへの秘密混入。どれも高度な攻撃ではなく、設定の抜けだった。

セキュリティ事故と聞くと、映画のようなハッキングを想像するかもしれません。

黒い画面に流れる緑の文字。天才ハッカーが暗号を破る。

現実は、もっと地味です。

実際の事故データを突き合わせると、小さなアプリの被害はたった3つのパターンに集中しています。

  • データベースに鍵をかけ忘れる（アクセス制御の未設定）
  • 見せてはいけない鍵を、見える場所に書く（秘密鍵の直書き）
  • Gitの履歴に秘密を残したまま公開する（.envのコミット）

今回は、この3つを実際に起きた事故で1つずつ見ていきます。すべて2025年から2026年にかけて実在したもので、出典を末尾に置いています。

ㅤ

過ち1: データベースの鍵のかけ忘れ

Case Study/ 米国/ 2025

CVE-2025-48757: Vibe Codingプラットフォームが量産した「開いたドア」

RLS未設定 · Supabase · Vibe Coding

ユーザー数800万人を超えるVibe CodingプラットフォームのLovableで、生成されるアプリのデータベース（Supabase）に行レベルセキュリティ（RLS）が設定されない問題が見つかり、CVE（共通脆弱性識別子）として登録されました。

確認されただけで170件以上の本番アプリが、ブラウザの開発者ツールから接続情報をコピーするだけで、データベースの全テーブルを読み書き削除できる状態でした。

前回の言葉で言えば、「ブラウザに届いたものは見える」の実例です。接続情報自体は見えてよい設計のものでしたが、データベース側の鍵（RLS）がなかったため、見えた情報がそのまま合鍵になりました。

ここで覚えてほしいのは、Supabaseなどのデータベースは、テーブルを作った直後は守られていない、ということです。

鍵をかけるのはあなたの仕事で、かけたかどうかを確かめるのもあなたの仕事です。Supabase公式ドキュメントも「RLSが有効でないテーブルは、誰でもデータの読み書き・改変ができる」と明記しています。

やり方は次回、手を動かしながら覚えます。今日は「初期状態は開いている」という事実だけ、持ち帰ってください。

ㅤ

過ち2: 見せてはいけない鍵の直書き

Case Study/ 米国/ 2026

Moltbook事件: 150万件のAPIキーが公開状態に

秘密鍵の露出 · クライアント直書き

誤設定されたデータベースから、約150万件のAPIキーと3.5万件のメールアドレスが誰でも読める状態になっていた事件です。

きっかけの一つは、本来サーバーの奥にしまうべき特権キーを、ブラウザに届くコードに直書きしていたこと。前回の地図で言う「ガラス張りの場所」に、金庫の鍵を貼り付けていた形です。

鍵には、見られてもよい鍵と、絶対に見られてはいけない鍵があります。

たとえばSupabaseなら、ブラウザ用の鍵（anon key）は見られる前提で設計されており、RLSと組み合わせて使います。一方、管理者用の鍵（service_role key）はRLSを素通しする万能鍵で、これがブラウザに置かれた瞬間、すべての防御が消えます。

この区別は第4回で表にして整理します。ここでは「鍵には種類があり、置き場所を間違えた瞬間に事故になる」ことだけ押さえてください。

ㅤ

過ち3: Gitの履歴に秘密を残す

3つ目は、いちばん「うっかり」が起きやすい場所です。

Case Study/ 世界/ 2026

State of Secrets Sprawl 2026: 年間2,900万件の秘密が公開リポジトリに

Git · 秘密情報の混入

GitGuardian社の年次調査によると、2025年の1年間だけで、公開リポジトリに約2,900万件の新規の秘密情報（APIキー・パスワード等）が混入しました。前年比で34%増、過去最大の増加幅です。

同調査は、AIコーディング支援が有効なリポジトリのほうが、秘密情報の漏洩率が40%高いというデータも報告しています。AIと一緒に高速で作るほど、うっかりの回数も増えるということです。

怖いのは、Gitには履歴が残ることです。

「しまった、消そう」とファイルを削除してコミットしても、過去の履歴をたどれば秘密は読めます。だから対処の第一手は削除ではなく、その鍵を無効化して新しい鍵に替えること（ローテーション）になります。ここは第5回で手順まで落とします。

視点

私自身もやりました

正直に書くと、私も一度、認証情報の入ったファイルを誤ってコミットしかけたことがあります。気づいて即座にキーを無効化・再発行したので実害はありませんでしたが、「自分は気をつけているから大丈夫」が通用しないことを体で覚えました。仕組みで防ぐ方法（Push Protection）を第5回で導入します。

ㅤ

3つの過ちと、この講座の地図

今日の3つは、そのままこの講座の中盤3レッスンに対応しています。

過ち実例対策レッスン
データベースの鍵のかけ忘れCVE-2025-48757（170件超）第3回 RLS
秘密鍵の直書きMoltbook（150万キー）第4回 鍵の置き場所
Gitへの秘密混入年間2,900万件第5回 Gitと秘密情報

どれも、攻撃者が高度だったから起きたのではなく、守る側の設定が抜けていたから起きた。逆に言えば、設定さえ知っていれば、この3大事故のほとんどは防げます。

ㅤ

今日のまとめ

3行で振り返ります。

  • 小さなアプリの実被害は、RLS未設定・鍵の直書き・Gitへの秘密混入の3つに集中している
  • データベースは作った直後は開いている。鍵をかけるのは自分の仕事
  • Gitに混入した秘密は削除では消えない。無効化して替えるが第一手

ㅤ

次のレッスン

次回はいよいよ、事故原因の単独首位であるRLS（行レベルセキュリティ）を扱います。「テーブルを作った瞬間は全世界公開」という初期状態に、自分の手で鍵をかけ、かかったことをテストするところまでやります。

ㅤ

参考・出典