【入門編】危険なJavaScriptシンク（Sink）の特定と安全な代替API – アプリケーションセキュリティ & 安全な開発防御ガイド

「悪意あるスクリプト」を玄関に入れないために。XSSからWebサイトを守るDOM操作の鉄則

こんにちは。セキュリティの世界で泥臭い現場を駆け回っているエンジニアです。

皆さんは「XSS（クロスサイトスクリプティング）」という言葉を聞いたことはありますか？初心者向けのセキュリティガイドを読むと、決まって「恐ろしい攻撃」として紹介されていますよね。でも、いざコードを書くとなると、なぜそれが危険なのかピンとこないことも多いはずです。

今日は、小難しい理論は一旦脇に置いて、「Webサイトの玄関」という身近な例え話で、この攻撃の正体と、今日からできる一番確実な対策についてお話しします。

—

1. 泥棒は「あなたの親切心」を悪用する

想像してみてください。あなたのWebサイトは、大事なお客様（ユーザー）を迎える「お家」です。

XSS攻撃とは、「本来ならただのメッセージを書くはずの場所に、泥棒がこっそり『合鍵を作るための型』を置いていく」ようなものです。

例えば、掲示板や検索結果の画面。ここに悪意ある人が、こんなスクリプトを書き込んだとしましょう。

普通の人は「ただの文字」だと思うでしょう？しかし、ブラウザはこれを「命令」として受け取ってしまいます。
「おっ、スクリプトだ！実行しなきゃ！」と、あなたのサイトを表示した他のお客様のブラウザが、勝手にその命令を実行してしまうんです。結果、お客様のCookie（ログイン情報など）が泥棒の元へ送られてしまいます。これがXSSの恐ろしさです。

—

2. なぜ innerHTML が「危険な鍵」なのか

Web開発をしていると、画面を書き換えるために innerHTML を使いたくなる場面は多いですよね。

// 危険な例：ユーザーの入力をそのままHTMLとして解釈させてしまう
const userComment = ““;
document.getElementById(‘comment-box’).innerHTML = userComment;

innerHTML は、渡された文字列を「HTMLタグ」として解析しようとします。つまり、「玄関のドアに、鍵穴を勝手に増設していいよ」と許可を出しているのと同じなんです。泥棒にとって、これほど都合のいい状況はありません。

安全な代替API： textContent という「透明な壁」

そこで登場するのが textContent です。これを使うと、渡された文字列を「ただの文字」としてしか扱いません。たとえそこに