代表的な脆弱性を、自分のアプリで想像する

脆弱性の名前を暗記しても、自分のアプリのどこを見ればよいかは分かりません。この章では、論文で多かった上位5種類に3種類を加えた8種類を、「仕組み」「ミニ銀行で起きたら」「AIがやりがちな作り込み方」「塞ぎ方の方針」の4点で見ていきます。例はあなたの学習用ミニ銀行アプリです。攻撃の手順は書きません。起きたときに何が壊れるかを想像できれば十分です。

この章で扱う8種類

論文の上位5種類に、個人開発で起きやすいXSS、CSRF、秘密情報の漏えいを加えました。右端の列が、確認手順を扱う章です。

OWASP Top 10:2025では、XSSはインジェクション（A05）の一種で、秘密情報の漏えいは暗号化の不備（A04）や設定の不備（A02）にまたがります。自分のアプリで起きる場面が違うので、ここでは別に立てました。

「誰に何を許すか」の穴

第2章の図2-1でいう②の確認が、ない、または甘い。論文で1位と3位、合わせて4割を超える系統です。承認権限と職務分掌の不備に当たります。

1. アクセス制御の不備

• 仕組み。「このデータはこの人のものか」「この人は管理者か」をサーバーが確かめていない状態です。IDを指定すれば他人のデータに届く形を、IDOR（他人のデータのIDを指定すると見えてしまう不備）と呼びます。
• ミニ銀行で起きたら。利用者AがURLの口座番号を変えるだけで、利用者Bの残高と取引履歴が見えます。更新にも穴があれば、Bの口座から振込ができます。
• AIがやりがちな作り込み方。「ログイン済みか」だけを確かめ、所有者の確認を書かない。メニューを隠しただけで済ませる。第4章の「暗黙の規則の欠落」が最も典型的に現れる場所です。
• 塞ぎ方の方針。読む・書く・消すすべてのサーバー側処理で、所有者または役割を確認する。Supabaseなら、データベース側のRLS（行単位のアクセス制御）で二重に守る。OWASPのAuthorization Cheat Sheetは「すべてのリクエストで権限を検証し、初期状態は拒否」を基本としています。

2. 認証の不備

• 仕組み。本人確認そのものが甘い状態です。短いパスワードを許す、何度間違えても止まらない、ログアウトしてもログイン状態が残る、といった形です。
• ミニ銀行で起きたら。第三者がパスワードを当てて利用者Aとして入ります。アクセス制御が正しくても、本人として入られれば、Aの口座は自由に操作されます。
• AIがやりがちな作り込み方。「とりあえず動くログイン」。最小長なし、失敗回数の制限なし、ログアウトは見た目だけ。第4章の「デモ志向の設計」です。
• 塞ぎ方の方針。自作しない。Supabase Authのような認証サービスに任せ、設定画面でパスワードの最小長や失敗時の制限を確認する。ログアウト後に保護画面が残らないことを自分の目で確かめる。

「入力が命令になる」穴

入力欄は、利用者が自由な文字をサーバーに送り込める口です。その文字が「データ」として扱われるべきところで「命令」として解釈されると、この系統の穴になります。摘要欄の文字が会計システムへの命令になってはいけないのと同じです。

3. インジェクション

• 仕組み。入力された文字を、データベースへの命令文の中にそのまま貼り付けて組み立てている状態です。文字の中に命令として読める部分があると、サーバーはそれを実行します。
• ミニ銀行で起きたら。振込のメモ欄や検索欄から、全利用者の取引履歴が読み出されたり、残高が書き換えられたり、テーブルごと消されたりします。
• AIがやりがちな作り込み方。命令文を文字列の足し算で組み立てる書き方です。短く見えるので、AIが選びがちです。
• 塞ぎ方の方針。命令と入力を分けて渡す（プレースホルダーを使う）。Supabaseのクライアントや多くのデータベース用ライブラリは、正しく使えばこれを自動で行います。確認方法は第11章で扱います。

4. XSS（クロスサイトスクリプティング）

• 仕組み。入力された文字が他の利用者の画面にそのまま表示され、ブラウザがそれを「実行するプログラム」として解釈してしまう状態です。
• ミニ銀行で起きたら。利用者Aが振込メモに仕込んだ文字が、受け取った利用者Bの画面で動き、Bのログイン済みの証明を外部に送ります。Bは何もしていないのに乗っ取られます。
• AIがやりがちな作り込み方。見た目を整えるために、入力をHTMLとしてそのまま画面に挿入する機能を使う。第1章で触れたVeracodeの報告では、AIはXSSを86%のケースで防げていませんでした。
• 塞ぎ方の方針。表示するときにエスケープする（文字を文字のまま出す）。現代の画面用ライブラリは標準でこれを行うので、「そのまま挿入する」機能を使っている箇所がないかを探す。

5. CSRF（クロスサイトリクエストフォージェリ）

• 仕組み。ログイン中の利用者が別のサイトを開いたとき、そこからあなたのアプリへ操作の依頼が送られてしまう状態です。ブラウザがログイン済みの証明を自動で添えるため、本人の操作に見えます。
• ミニ銀行で起きたら。利用者Aがログインしたまま怪しいページを開いた瞬間に、Aの口座から振込が実行されます。Aは振込画面を見てすらいません。
• AIがやりがちな作り込み方。残高を変える操作を、確認なしに受け付ける形で作る。「言われなければ対策しない」ものの代表です。
• 塞ぎ方の方針。残高や設定を変える操作には、そのページから来たことを示す使い捨ての札（CSRFトークン）を要求する。OWASPのCSRF Prevention Cheat Sheetが基準で、多くのフレームワークに標準の仕組みがあります。

「保管と設定」の穴

データの置き方と、公開先の設定の問題です。金庫の中身の保管方法と、金庫の鍵の管理に当たります。

6. 暗号化の不備

• 仕組み。パスワードを元の文字のまま（平文で）保存している、暗号化しているつもりで何もしていない、誰でも知っている固定の鍵を使っている、といった状態です。
• ミニ銀行で起きたら。データベースが一度でも読まれると、全利用者のパスワードがそのまま流出します。他のサービスでも同じパスワードを使っている利用者は、そちらも乗っ取られます。
• AIがやりがちな作り込み方。「暗号化する」という名前の関数の中身がダミー、鍵がコードに直書き。第4章の「デモ志向の設計」の代表例です。
• 塞ぎ方の方針。パスワードは自分で保存せず、認証サービスに任せる。自分のテーブルにパスワードの列があるなら、ハッシュ化（元に戻せない形への変換）されているかを確かめる。

7. 設定の不備

• 仕組み。コードは正しくても、VercelやSupabaseの設定が初期状態のまま、または緩い状態です。RLSが無効、エラー画面に内部情報が出る、試作用のURLが誰でも見られる、など。
• ミニ銀行で起きたら。RLSが無効なら、公開用の鍵だけで全テーブルが読めます。コードで所有者を確認していても、データベースに直接届く経路が開いています。
• AIがやりがちな作り込み方。AIは管理画面の設定を変えられません。「設定は利用者がしてください」と委ねたまま公開されます。第4章の「利用者任せ」です。
• 塞ぎ方の方針。管理画面を自分の目で見る。Supabaseの公式ドキュメントは、外部に公開されるテーブルすべてでRLSを有効にすることを求めています。第12章で一つずつ確認します。

8. 秘密情報の漏えい

• 仕組み。APIキー、データベースの接続情報、管理用の鍵が、コードの中、Gitの履歴、ブラウザに届くコードのどこかに入っている状態です。
• ミニ銀行で起きたら。Supabaseの管理用の鍵（secret／service_role）が漏れれば、RLSを素通りして全データが読み書きされます。AIのAPIキーなら、あなたの課金で他人が使います。
• AIがやりがちな作り込み方。「とりあえず動くように」鍵をコードに直書きし、環境変数に移すのを忘れる。第4章の「先送りの忘却」です。
• 塞ぎ方の方針。鍵はすべて環境変数に置き、コードとGitとブラウザには入れない。漏れた鍵は再発行する。第9章で、検索と目視だけで棚卸しします。

用語の整理

IDOR

Insecure Direct Object Reference。データのID（口座番号、伝票番号）を指定すると、持ち主でなくても届いてしまう不備。アクセス制御の不備の最も典型的な形。

エスケープ

入力された文字を画面に出すとき、命令として解釈されうる記号を「ただの文字」に変換すること。XSSの基本的な守り。

プレースホルダー

データベースへの命令文の中に「ここに入力が入る」という空欄を置き、命令と入力を分けて渡す方法。インジェクションの基本的な守り。

ハッシュ化

パスワードなどを、元に戻せない固定長の文字列に変換すること。保存するのは変換後の値だけで、照合は入力を同じ方法で変換して比べる。

RLS

Row Level Security。データベースの側で「誰がどの行を読めるか」を決める仕組み。Supabaseでは、公開用の鍵で届く要求はRLSに従って絞られる。