Vue.jsの v-html という「劇薬」：その利便性の裏に潜むXSSの罠
現場でコードレビューをしていると、必ずと言っていいほど遭遇するのが v-html の安易な使用だ。CMSで作成されたリッチテキストを表示したい、あるいは外部APIから受け取ったHTMLをそのまま描画したい。理由は様々だが、セキュリティの観点から言えば、それは「ブラウザに対して、信頼できない入力をそのままDOMとして実行させる」という、極めて危険な行為に他ならない。
今日は、Vue.jsにおけるXSSの核心と、その「劇薬」とどう付き合うべきか、泥臭い実務の話をしよう。
—
1. なぜ v-html は危険なのか？
Vue.jsの強力な武器である「テンプレート構文」は、デフォルトでは {{ }}（マスタッシュ構文）を使う限り、変数の内容をHTMLエスケープしてくれる。しかし、v-html を使った瞬間、Vueはその防御バリアを解除する。
攻撃者が狙う「DOMの隙間」
例えば、ユーザーのプロフィール欄を以下のように実装しているとしよう。
ここで攻撃者が userProvidedContent に以下のようなペイロードを送り込んだらどうなるか。
ブラウザは src="x" という読み込みに失敗し、即座に onerror イベントを発火させる。結果、管理者のセッションクッキーが盗まれる、あるいは悪意のあるスクリプトがWebアプリのコンテキストで実行される。これが「DOM型XSS」の典型的な入り口だ。
—
2. 防御の鉄則：サニタイズなしにレンダリングするな
「信頼できるソースからしかデータは来ない」という性善説は、セキュリティの世界では通用しない。社内ツールであっても、バックエンドのバリデーションが甘い箇所があれば、そこが侵入経路になる。
推奨：DOMPurifyによるホワイトリスト制御
v-html を使うなら、必ず「サニタイズ（無害化）」を挟むこと。自前で正規表現を書いてHTMLを除去しようとするのは、「セキュリティの再発明」であり、100%脆弱性が残ると心得ておけ。
圧倒的な信頼性を誇るライブラリ DOMPurify を使うのが正解だ。
実装サンプル (Vue 3 / JavaScript)
import DOMPurify from ‘dompurify’;
// 算出プロパティでサニタイズ済みのHTMLを生成する
computed: {
sanitizedContent() {
// 許可するタグや属性を詳細に設定可能
return DOMPurify.sanitize(this.userProvidedContent, {
ALLOWED_TAGS: [‘b’, ‘i’, ‘em’, ‘strong’, ‘a’],
ALLOWED_ATTR: [‘href’]
});
}
}
これだけで、onerror や
コメント