ブラウザの「親切心」が招く悲劇：オートコンプリートとXSSの危険な関係
現場でコードレビューをしていると、機能性ばかりを優先して「ブラウザの便利機能」を野放しにしているエンジニアによく遭遇する。中でも、特に見落とされがちなのがタグのautocomplete属性だ。
「入力の手間が省けてユーザー体験（UX）が向上する」――。その言葉は甘美だが、セキュリティの最前線にいる我々からすれば、それは「機密情報をブラウザのローカルDBに保存し、攻撃者のスクリプトに差し出している」のと同じことだ。
今日は、オートコンプリートが悪用された際の脅威と、現場で即座に適用すべき防御策について、綺麗事抜きで解説する。
—
1. なぜオートコンプリートが攻撃対象になるのか
ブラウザのオートコンプリート機能は、ユーザーが過去に入力した情報を記憶し、フォームに自動補完する。これは一見便利だが、悪意ある攻撃者から見れば、「ユーザーの入力値を強制的に引きずり出すための餌」だ。
攻撃シナリオ：XSSとの合わせ技
もし君が開発するアプリケーションに、極めて軽微なXSS（クロスサイトスクリプティング）の脆弱性が残っていたとしよう。通常、XSSだけで機密情報を奪うには、ユーザーが手動で入力するのを待つ必要がある。
しかし、オートコンプリートが有効な場合、攻撃者は以下の手順で情報を抜き取る。
1. 罠の設置: 攻撃者はサイト内の掲示板やプロフィール編集欄など、XSSが刺さる場所に悪意あるスクリプトを仕込む。
2. 自動入力の誘発: ユーザーがログインフォームや住所入力フォームにアクセスすると、ブラウザが勝手に「名前」「メールアドレス」「電話番号」「クレジットカード情報の一部」をフォームに流し込む。
3. スクリプトの実行: 攻撃者のスクリプトは、フォームが自動入力された瞬間にその値を読み取り、外部サーバーへ送信（Exfiltration）する。
ユーザーが何もキーを叩いていなくても、ページを開いただけで個人情報が流出する。これがオートコンプリートを無防備に放置する最大のリスクだ。
—
2. 実務で即座に適用すべき「防御の最適解」
対策はシンプルだ。「機密性の高いフィールドでは、ブラウザに保存させない」。これに尽きる。
具体的な実装サンプル（HTML）
最も基本的かつ強力な防御は、autocomplete="off" を適切に設定することだ。しかし、これだけでは古いブラウザや一部の挙動を完全に抑制できない場合がある。
ポイント:
autocomplete="off"は万能ではない。ブラウザによっては無視されることもあるため、autocomplete="new-password"（パスワード変更時）やautocomplete="off"を組み合わせるのが鉄則だ。- そもそも論: XSSの脆弱性自体を潰すことが大前提だ。
Content-Security-Policy (CSP)をヘッダーで設定し、インラインスクリプトを禁止することが、現代のWeb開発における最低限の防波堤となる。
—
3. 防御の最終防衛ライン：CSPの設定
ブラウザの機能に頼るだけでなく、サーバー側から「スクリプトの実行ルール」を強制しよう。Nginxでの設定例を記す。
Nginx設定ファイルに追加
信頼できるソースからのスクリプトのみ実行を許可する
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘none’;”;
セキュアなCookie属性（念のためのインジェクション対策）
add_header Set-Cookie “HttpOnly; Secure; SameSite=Strict”;
script-src 'self': 外部からの怪しいスクリプト実行をブロックする。これで、万が一XSSの脆弱性が埋め込まれても、攻撃者の外部サーバーへ情報を飛ばす通信を遮断できる。object-src 'none': プラグイン経由の攻撃を封じる。
—
最後に：エンジニアとしての心得
「機能開発に追われてセキュリティがおろそかになる」というのは、どの現場でも起こる言い訳だ。しかし、顧客の信頼を一度の流出で失うコストを考えれば、autocomplete="off" を一行書く手間など、ゼロに等しい。
コードを書くとき、常に自問自答してほしい。「このブラウザの親切機能は、攻撃者にとっての扉になっていないか？」と。
技術は常に進化する。だが、攻撃者はいつだって「エンジニアが油断した場所」を狙っている。君たちの手で、その扉を確実に閉ざしてくれ。それが、プロフェッショナルとしての仕事だ。
コメント