蓄積型XSSの深淵：データベースは「信頼の起点」ではなく「汚染の温床」である
諸君、コードを書き、システムを設計する日々ご苦労様だ。
セキュリティの現場に長く身を置いていると、「入力値検証（バリデーション）」を万能薬と信じ込んでいる開発者にしばしば出会う。だが、ハッキリ言っておく。データベース（DB）に保存されたデータは、決して「信頼されたデータ」ではない。
今日は、蓄積型XSS（Stored XSS）という、一見古典的だが、現代の複雑なSPA（Single Page Application）やマイクロサービス環境下では致命傷となり得る脆弱性の本質について、泥臭い実装の裏側から解剖していく。
—
1. なぜ「データベース」が脆弱性の震源地となるのか
蓄積型XSSの恐ろしさは、攻撃者が「一度の汚染」で「永続的な影響」を広範囲に及ぼせる点にある。SQLインジェクションがDBの中身を盗むものだとすれば、蓄積型XSSはDBそのものを「攻撃コードの配布プラットフォーム」へと変貌させる行為だ。
ここで見落とされがちなのが、ORM（Object-Relational Mapping）の盲点だ。多くの開発者は、ORMがよしなにデータをエスケープしてくれると信じている。しかし、ORMはSQLインジェクションを防ぐためのバインド変数を生成するだけであり、「保存されたテキストデータが、フロントエンドのブラウザでどのように解釈されるか」というコンテキストまでは関知しない。
もし君たちが、DBから取り出した値をそのままReactの dangerouslySetInnerHTML に流し込んだり、Vue.jsの v-html でバインドしたりしているなら、それは時限爆弾を抱えて寝ているのと同じだ。
2. コンテキスト依存の出力エスケープ：防衛の最後の砦
対策はシンプルだ。「DBに入れる前にエスケープする」という古い定説は半分間違いだ。正しくは「出力するコンテキストに応じて、実行直前にエスケープする」のが現代のアーキテクチャの鉄則である。
なぜなら、HTMLのボディ内、属性値内、あるいはJavaScriptの文字列リテラル内では、無効化すべき「メタ文字」が異なるからだ。
実践的なエスケープの考え方（Node.js / Expressの例）
例えば、ユーザーのプロフィール欄をレンダリングする際、単純なHTMLエスケープだけでは不十分なケースがある。
// 脆弱な例：単純なエスケープのみでは「属性コンテキスト」で回避される可能性がある
const sanitizeHtml = require(‘sanitize-html’);
// 悪い例: 直接テンプレートに埋め込む
//
// 良い例: 出力時にコンテキストを意識した処理を行う
function renderUserProfile(bio) {
// HTMLタグを許可しつつ、悪意ある属性（onmouseover等）を徹底的に除去する
// 単なるエスケープではなく、ホワイトリスト方式のサニタイズが必須
return sanitizeHtml(bio, {
allowedTags: [‘b’, ‘i’, ‘em’, ‘strong’],
allowedAttributes: {
‘a’: [‘href’] // リンク先もプロトコル制限（javascript:スキーム等）を考慮すべき
}
});
}
3. 進化する攻撃：生成AI時代のプロンプト・インジェクションとの融合
今の攻撃者は、ただ
コメント