2026 年 1 月下旬。開発者は週末にソーシャルネットワークを出荷します。従来のコードは書かれず、プロンプト、ビジョン、そしてアイデアを数日で動作するプロダクトに変える AI だけです。プラットフォームはウイルス化します。Open AI の共同創設者である Andrej Karpathy は、「私が最近見た中で最も信じられない SF の離陸に隣接したものです。“
セキュリティリサーチ者がブラウザの開発ツールを開きます。
数分以内に、プレーン Java Script での API キーを見つかりました。 F 12 を押す方法を知っている人は誰でも見えます。プロダクションデータベースに問い合わせるために使用します。ログイン不要です。特殊な道具なし。簡単なコマンドとコーヒーのみ。
戻ってくるもの : 1.5 API 認証トークン数百万。35,000 の電子メールアドレス。数千のプライベートメッセージ。 すべてのエージェント、すべての資格情報、すべての会話など、プラットフォーム全体が広く開かれています。
プラットフォームは Moltbook と呼ばれた。修正が来たとき、 2 つの SQL ステートメントを取りました。
これは悪い開発者の話ではない。AI が自動的に埋められないギャップと、出荷前に何ができるかについての物語です。
みんなをキャッチする幻想
数年前、ソフトウェアを構築するには痛い障壁を渡らなければならなかった。構文、フレームワーク、データベース、 API 、 Git 、デプロイメントを学び、その過程で何度も破壊する必要がありました。テクノロジー以外のほとんどの人々にとって、ソフトウェアエンジニアリングはドアが非常に小さい鍵をかけられた部屋のように感じました。
そして AI が到着。
従来のプログラミングの経験が少ない人は、週末で SaaS アプリを構築し、データベースをフロントエンドに接続し、支払いを統合し、 API をデプロイすることができます。その変化は並外れたもので、本当に素晴らしいと思います。私もバイブコーダーです。アイデアが想像力から実用的な製品にこれまで以上に速く動くのを見る興奮は理解しています。
しかし、 AI が生成したソフトウェアの周りには危険な錯覚が形成されています。 アプリが動作すれば、人々はそれが安全であると仮定します。これらは同じものではない。
美しく設計されたアプリケーションでも、個人ユーザーデータの公開、 API キーの漏洩、不正アクセスの許可、誤ってデータベース保護の無効化が可能です。セキュリティ問題は目に見える機能の下にあります。それがまさに Moltbook に起こったことです。
AI が正しく、静かにスキップするもの
AI は、機能が動作し、ボタンが応答し、 API がデータを返し、ページがレンダリングされるなど、幸せなパスを構築するのに非常に優れています。その部分は本当に印象的です。
セキュリティは不幸な道に住んでいる :
- ログインせずにデータベースに問い合わせたら ?
- 攻撃者がブラウザからのリクエストを操作した場合 ?
- API キーがページソースに表示されている場合は ?
- 誰かがあなたの登録エンドポイントをループで 1 万回呼び出した場合 ?
経験豊富な開発者は自動的に質問します。彼らが賢いからではなく、痛みを伴う問題のデバッグ、検死検死の結果を読み、リスクの低い環境で間違いを犯して、習慣をゆっくりと築いたからです。
AI は実装タイムラインを劇的に圧縮します。適切なセキュリティ質問をするために必要な経験を圧縮しません。そのギャップは違反が発生する場所です。
そして明確にするために : これは初心者の問題だけではありません。経験豊富な開発者でも AI が出力速度を加速すると自信過剰になります。AI 生成のコードはしばしば非常に説得力があるからです。説明は自信に満ちている。建築はもっともらしい。機能は正しく機能します。
しかし、もっともらしいコードは安全なコードと同じではない。
The Moltbook Breakdown : What Actually Went Wrong
Moltbook は、高速開発に優れた人気のあるドキュメント化されたバックエンドサービスである Supabase 上に構築されました。Supabase は、クライアント側で公開された公開 API キーで動作するように設計されています。それは意図的であり、それ自体がセキュリティ障害ではありません。
セキュリティ障害は、そのキーを設定して行うことができます。
Supabase には、ユーザーが自分のデータにのみアクセスできるようにするデータベース設定である Row—Level Security と呼ばれる機能が付属しています。デフォルトでは有効ではない。オンにする必要があります。そして、あなたが Vibe コーディングをしている場合、 AI がセキュリティについて尋ねずに動作するバックエンドを生成すると、そのステップが起こらない可能性が高いです。
Moltbook では、そうではありません。
結果 :基本的な技術的知識を持つ誰でも、ウェブサイトの目に見えるキーを使って、すべてのユーザーの資格情報、プライベートメッセージ、認証トークンなどの本番データベース全体をクエリできます。書き込みアクセスも開いていたため、攻撃者はログインせずにプラットフォーム上の投稿を編集することができました。
創設者の公式声明は状況を正直に捉えた。 「私は Moltbook のためのコードを一行も書かなかった。技術的なアーキテクチャのビジョンを持っていたばかりで、 AI がそれを現実のものにした。"
AI は作業プラットフォームを作った。それは安全なものではなかった。
It 's Not Just Moltbook
Moltbook の 6 ヶ月前、 Wiz のセキュリティ研究者は Base 44 に重大な脆弱性を発見しました。 Base 44 は、実際の企業が社内人事システム、顧客データベース、機密従業員データを含むナレッジベースを構築するために使用する Vibe コーディングプラットフォームです。
ユーザの登録と検証のための 2 つの API エンドポイントは認証を必要としません。アプリのパブリック URL に表示される値のみを使用することで、 SSO やその他のアクセス制御を完全にバイパスして、プラットフォーム上のプライベートエンタープライズアプリケーション内で検証済アカウントを作成できます。
会話を変える詳細は次のとおりです。 Base 44 ビルダーは脆弱なエンドポイントを書かなかった。プラットフォームはそうしました。 個々の開発者はこの欠陥を視認できなかった。これは、ほとんど誰も話さない vibe coding セキュリティリスクの 2 つ目の次元です。1 つ目は、プロンプトを提示したときに AI が生成するものです。 2 つ目は、構築中のプラットフォームがコードとは独立して導入するものです。
両方とも重要です。両方とも対応できる。
プレーン英語のセキュリティ
セキュリティが恐ろしく感じる理由の 1 つは、用語が抽象的で技術的に聞こえるからです。そのほとんどはそうではありません。ここでは、最も頻繁に現れる概念のプレーン英語翻訳です :
| 期日 | 実際の意味 |
|---|---|
| 認証 | 誰かを確認する |
| 認可 | アクセス許可の決定 |
| API キー | App が他のサービスと通信するために使用する秘密パスワード |
| ローレベルセキュリティ | ユーザーがデータベース内の他のユーザーのデータを読み込むのを防ぐ |
| レート制限 | 誰かのループで数千のリクエストを行うのを防ぐ |
| 秘密スキャン | コード内の公開されたパスワードやキーを自動的に検出 |
| 最小権限 | システムに実際に必要とする最小限のアクセスのみを与える |
| 入力検証 | ユーザーが危険なデータや予期せぬデータを送信できないようにする |
セキュリティは魔法ではない。ほとんどの場合、明らかな間違いを削減し、間違いが発生した場合の損害を制限し、ユーザーの信頼を保護することです。それだけだよ
AI が一貫して見逃す 5 つのこと
これらは、エキゾチックなエッジケースとしてではなく、デフォルトとして、 AI が生成したコードで繰り返し現れるパターンです。それぞれが実用的な修正が付属しています。
1.クライアントサイドコードで公開される API キー
AI にアプリを外部サービスに接続するよう依頼すると、しばしばフロントエンドコードに直接資格情報を置きます。フロントエンドのコードは公開です。誰でもブラウザの開発者ツールを開いて見つけることができます。自動スキャナがウェブをクロールしてまさにこれを探します。
修正 : 走る ギトレイクス コードを押す前秘密をスキャンし、見つかった場合はコミットをブロックします。GitHub の内蔵の秘密スキャンは、パブリックリポジトリでも自動的に同じことを行います。
2.行レベルのセキュリティが有効ではない
これが Moltbook の失敗です。なぜなら、 RLS はデータアクセスモデルを理解する必要があり、明示的に要求しない限り、 AI はしばしばその推論をスキップするためです。
修正 : Supabase のダッシュボードで、ユーザーデータを含むすべてのテーブルで RLS が有効になっていることを確認します。次に、各行にアクセスできる人を正確に定義するポリシーを記述します。Supabase のドキュメントには、約 20 分かかる初心者に優しいウォークスルーがあります。
-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);
3.認証なしの API エンドポイント
AI はリクエストに応答するルートを生成します。これらのルートに認証を追加するかどうかは、尋ねたかどうか、 AI がそのファイルに到達するまでに以前の要件を覚えたかどうかによって異なります。
修正 : すべての API ルートを見て、ログインせずに誰かがこれを呼び出した場合はどうなりますか ?ツールなど ベアヤー コードベースをスキャンし、無償で保護されていないルートをフラグ付けします。さらに、ミドルウェア層で認証を適用して、すべてのルートがデフォルトで保護されます。
4.アプリの間違った側面の秘密
多くの AI ツールはハードコードの秘密を知らず、環境変数を提案します。クライアント ( パブリック ) で利用可能な変数とサーバ ( プライベート ) でのみ利用可能な変数の違いを見逃すこともあります。
Next.js では、と接頭する変数 NEXT_PUBLIC_ Java Script クライアントにバンドルされ、誰もが可視です。Open AI API キー、 Stripe 秘密キー、およびデータベース資格情報にはその接頭辞を持つべきではありません。
修正 : プロジェクトを検索する NEXT_PUBLIC_ 機密性のないものを使用していないことを確認します。Supabase URL のようなパブリック設定値は、 RLS が適切に設定されている場合に限って、プレフィックスを安全に使用できます。
5.無料制限
AI はリクエストに応答するエンドポイントを生成します。要求しない限りレート制限を追加しません。つまり、登録エンドポイント、ログインエンドポイント、およびデータエンドポイントは誰からのリクエストを無制限に受け付けます。
Moltbook では、 1 つのボットが 50 万の偽アカウントを作成しました。同じパターンは、一晩で API クォータを使い果たし、プロジェクトを終了する請求書を実行するために使用できます。
修正 : Vercel を使用している場合は、プロジェクトのセキュリティ設定でレート制限を有効にします。 5 分かかり、コードは必要ありません。Supabase の場合、同じオプションはプロジェクトの設定にあります。公開する前にこれを行ってください。
ほとんどの人が犯す間違い : 「後で確保します」
このマインドセットは理解できます。学習しているとき、出荷はすでに十分に難しい感じます。セキュリティは、将来のバージョンのあなたにとって高度なトピックのように感じることができます。
問題は、セキュアでないアーキテクチャが非常に早く硬化することです。実際のユーザーが到着すると、技術的な負債複合物、コードベースに広がる安全でないパターン、漏洩した秘密は暴露できません。Moltbook の侵害は、創設者が後でセキュリティを修正する予定だったので起こらなかった。その瞬間が来る前にプラットフォームがウイルス化したからです。
セキュリティは、最後に追加された装飾的なレイヤーではありません。それはデザインの一部です。打ち上げる前に完璧が必要ではありません。つまり、セキュリティ意識は他のすべてのものと同時に始まる必要があります。
シンプルに保たれたセキュリティスタック
セキュリティエンジニアになる必要はありません。短いチェックリストとそれを実行する規律が必要です。
ここから始める — これらは合計 1 時間未満かかります :
- GitHub Secret Scanning— パブリックリポジトリでデフォルトで有効で、公開されたキーを自動的にキャッチします。
- Gitleaks— プッシュする前にローカルで実行します;secret を含むコミットをブロックします
- Supabase RLS— ダッシュボードのすべてのテーブルで有効にします。ドキュメントのウォークスルーに従ってください。
- Vercel Rate Limiting— 公開前にプロジェクトの設定で有効にします
- Snyk free tier— 既知の脆弱性をスキャンする依存関係。VS Code
プロジェクトがより真剣になった場合 :
- Semgrep—CI
- CodeQL で安全でないコードパターンをキャッチする静解析— GitHub のプルリクエストワークフローに統合されたより深い分析
- Pre—commit フック— 危険なコミットをマシンから離れる前に停止する
これらのツールは自動化されたセカンドオピニオンと考えてください。AI が急速に動くジュニア開発者であれば、セキュリティツールは自動レビューアです。その組み合わせは、直感だけに頼るよりはるかに安全です。
もう一つ : AI に尋ねてください
Vibe コーディングのセキュリティで最も使用されていないテクニックの 1 つは、単にプロンプトを表示することです。ユーザーデータに触れる機能を出荷する前に、次のことを試してみてください :
"セキュリティ上の問題についてこのコードを確認します。クライアントサイドコードで認証情報が公開されているかどうか、データベーステーブルの行レベルセキュリティが有効になっているかどうか、 API エンドポイントが認証を必要とするかどうか、登録とデータエンドポイントにレート制限があるかどうかを確認します。"
AI は、明示的に求められた場合のセキュリティレビューが非常に可能です。問題は、そのレビューを自動的に適用しないことです。尋ねる習慣を作ってください。30 秒かかりますが、物事をキャッチします。
批評家に対する公正な聴聞会
バイブコーディングに反対する人々は間違っていません。AI は、訓練を受けた開発者が決してスキップしない仮定をスキップする動作コードを生成します。Moltbook と Base 44 はその有効な証拠です。
しかし、伝統的なコーディングのバックグラウンドを持たない人はものを構築すべきではないという結論は従わない。セキュリティ意識のないバイブコーディングは危険ですそれは別の主張であり、別の解決策があります。
両方の脆弱性を発見した同じチームである Wiz Research チームは、 Vibe コーディングを遅らせることではなく、それを向上させることです。 Supabase バックエンドを生成する AI ツールは、デフォルトで RLS を有効にすることができます。デプロイメントプラットフォームは、公開された資格情報を自動的にスキャンできます。デフォルトによるセキュアな Vibe コーディングのためのインフラストラクチャが存在する。それはまだデフォルトではありません。
それまでは、何をチェックすべきかを知っているビルダーによってギャップを埋めなければなりません。
出荷前
[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see
AI はソフトウェア作成をこれまで以上にアクセシブルにしています。より多くの人々を構築することは、よりイノベーション、より創造性、より多様な声がテクノロジーに参入することを意味します。これは本当に良いことです。
しかしソフトウェアエンジニアリングは常に動作するコードを生成する以上のものですすべてのアプリケーションの下には、信頼性、セキュリティ、権限、責任など、それを出荷した人に属するレイヤーがあります。
構築する前にすべてを学ぶ必要はありません。レイヤーが存在していることを知り、それをチェックする習慣を作る必要があります。
チェックリストは上記です。ツールは無料である。残りは規律である。ソフトウェアの未来は AI アシストかもしれない。しかし、責任はまだ人間です。
役に立ちましたか ?最初の AI 構築アプリを出荷したばかりの人と共有してください。それを最も必要とする人は、通常、まだ必要性を知らない人です。










