バイブコーディングの脆弱性を防ぐ方法とは？

TL;DR

AIでWebアプリを作る際は、メール確認や多要素認証を導入し、必要な列だけを取得して、RLSでユーザーごとのアクセスを制限する。Reactの自動エスケープを維持し、dangerouslySetInnerHTMLを避け、必要な場合は投稿内容をサニタイズすることが重要である。

Transcript

はい、どうもしです。え、今回はですね、 バイブコーディングに潜むセキュリティ ホール脆弱性について学ぶ動画を撮って いきたいと思います。ま、最近ね、バイブ コーディング、ま、クロードコードとか カソルとかを使ったバイブコーディングが 終了になってきて、今話題になってるのが 、え、セキュリティホール産んでしまうん じゃないかなっていうのが最近話題になっ てますよね。ま、だから今回はですね、 あえて脆弱性のあるweアプリケーション を作ってみて、それに対して攻撃をして みようとハッキングをして、え、どういっ た危険性があるのかってのを理解して いただくという動画を撮っていきます。で 、攻撃だけじゃなくて、じゃ、それを防ぐ ためにはどういう実装をすればいいのかに ついてもですね、軽く解説していきま... Read More

Key Insights

• メール確認は、登録者が入力したメールアドレスを実際に所有しているか確かめ、他人のアドレスを使ったなりすまし登録を防ぐための基本的な認証手段である。
• パスワードは、Supabase利用時にauth.users側で処理されるため、アプリケーションの公開テーブルへ別途保存してはならない機密情報である。
• RLSは、auth.uid()とprofilesテーブルのuser_idが一致する場合だけ取得を許可することで、ログイン中の本人以外によるデータ閲覧を防ぐ仕組みである。
• アスタリスクによる全列取得は、不要なメールアドレスなどまで読み込む過剰なデータ露出を招くため、クエリでは利用目的に必要なカラムだけを指定すべきである。
• クライアント側の表示制限は、データそのものへの第三者アクセスを防ぐ境界にはならないため、データベース側のRLSポリシーと組み合わせる必要がある。
• Reactの通常の文字列描画は、投稿されたHTMLタグをエスケープするため、入力されたscriptタグが画面上で直ちにJavaScriptとして実行される状態を避けられる。
• dangerouslySetInnerHTMLは、未処理の文字列をHTML構造へ直接挿入するため、第三者が投稿できる場所で使うと、imgタグのonerrorなどによるXSSを許す危険がある。
• サニタイズは、dangerouslySetInnerHTMLが必要な場合に投稿内容を処理し、危険なHTMLとして認識、実行されることを抑えるための対策である。
• 🎬 このチャンネルの他の動画:
  • ZedでClaude Codeを快適に使う方法
  • Claude Codeで自律開発組織を作る方法
  • Cursor 2.0でAIアプリを開発する方法
• 📺 このチャンネル: プログラミングチュートリアル

Questions & Answers

Q: バイブコーディングで作ったWebアプリの脆弱性を防ぐ方法は？

認証、データアクセス、画面描画の三層を確認することが対策の中心である。メール確認やGoogle認証を利用し、パスワードを公開テーブルへ保存しない。クエリでは必要な列だけを取得し、RLSで本人のデータだけに制限する。投稿内容は通常のReact描画を使い、HTMLを直接挿入する場合はサニタイズする。

Q: メール確認を無効にすると、なぜなりすましが起きるのか？

入力されたメールアドレスの所有者であることを確認しないままアカウントを利用できるからである。第三者が他人のメールアドレスで先に登録すると、本来の所有者が初めて登録しようとした際に、すでに存在するアカウントとして扱われる。確認メールのURLを開かせる設定が基本的な対策となる。

Q: Supabaseでパスワードを安全に保存する方法は？

パスワードはアプリケーション側のpublicテーブルへ保存せず、Supabaseの認証機能に処理を任せる。動画内の例では、パスワードはauth.usersテーブル側へ処理された状態で保存されるため、profilesなどにpasswordカラムを追加する必要はない。漏洩時の不正ログインが心配な場合は、多要素認証も検討する。

Q: SupabaseのRLSで本人のデータだけを取得する方法は？

SELECTポリシーに、auth.uid()とprofilesテーブルのuser_idが等しい場合だけ許可する条件を設定する。誰でも取得できるtrueの条件では、ほかのユーザーの情報まで閲覧される可能性がある。画面上で他人のデータを隠すだけでは不十分であり、Supabase側で取得そのものを拒否する必要がある。

Q: データ取得でアスタリスクを避けるべき理由は？

アスタリスクはテーブル内のすべての列を取得するため、画面に不要なメールアドレスなどの情報まで読み込む過剰なデータ露出につながるからである。ユーザー名だけが必要ならusernameだけを指定するなど、利用目的に必要なカラムへ限定する。これはセキュリティとパフォーマンスの両面に関係する。

Q: Reactではscriptタグを投稿されてもXSSは発生しないのか？

通常のReact描画では文字列が自動的にエスケープされるため、動画の例で投稿したscriptタグは文字として表示され、実行されなかった。ただし、すべての実装が安全という意味ではない。dangerouslySetInnerHTMLへ未処理の投稿内容を渡すと、HTMLとして解釈され、別の属性を通じてJavaScriptが実行され得る。

Q: dangerouslySetInnerHTMLが危険なのはなぜですか？

渡された文字列をHTML構造へ直接挿入し、Reactの通常のエスケープを回避するためである。動画の実演では、存在しない画像を指定したimgタグのonerror属性からJavaScriptが動作し、警告表示や画面全体の表示変更が起きた。第三者が投稿できるコメント欄などでは、特に利用を避ける必要がある。

Q: dangerouslySetInnerHTMLを使う必要がある場合の対策は？

挿入前のコンテンツをサニタイズし、危険なタグや属性がHTMLとして実行されないように処理する。特に、誰でも投稿できる記事やコメントでは、未処理の入力を直接渡してはいけない。投稿内容の表示にはマークダウンエディターのライブラリーを導入する方法も、動画内の選択肢として挙げられている。

Summary & Key Takeaways

• 認証では、Supabaseの確認メールを無効にすると、他人のメールアドレスを使った登録やなりすましが可能になる。確認メールを有効にするか、Google認証を採用することが基本対策となる。パスワードは公開テーブルへ保存せず、漏洩時の被害を抑えたいサービスでは多要素認証も検討する。

• データ取得では、profilesテーブルに対するアスタリスク指定が全列の過剰取得につながる。必要なカラムだけを明示するとともに、RLSのSELECT条件をauth.uid()とuser_idが一致する場合に限定する。画面側で表示を隠すだけではなく、データベース側で第三者の取得を拒否することが重要である。

• XSS対策では、Reactが通常の文字列表示を自動的にエスケープするため、投稿されたscriptタグはそのまま実行されない。一方、dangerouslySetInnerHTMLへ未処理の投稿内容を渡すと、imgタグのonerrorなどからJavaScriptが動作し得る。利用を避け、必要なら内容をサニタイズする。