セキュリティを整える
専門XSSのしくみを整える。
＝ 入力をそのまま画面に出すと、なぜ危ないのかを安全に体感
『入力をそのまま画面に出すと、なぜ危ないのか』——XSS（クロスサイトスクリプティング）を、安全な環境で自分の目で確かめるための防御教育ツール。危険な実装と、エスケープした安全な実装を並べて対比します。scriptは必ず無効化されるので、実際には何も実行されません。送信ゼロ・登録不要。
🔰 かんたんに言うと
サイトに入力した文字が「命令」として実行されてしまう不具合（XSS）を、安全な箱の中で体験します。
TLDR — 30秒で分かる
入力を信用してHTMLに入れると何が起きるかを、scriptが無効化された安全な環境で対比体験。防ぎ方も学べる。
主な機能を見る
- 危険な実装と安全な実装を2パネルで横並び対比
- 入力はsandbox付きiframeに隔離（allow-scripts無し）でscriptは絶対に実行されない
- エスケープ後の安全なHTMLをその場で確認・コピー
- 格納型XSS（入力→保存→他人の画面で発火）をStepDiagramで図解
- 出力時エスケープ/textContent/CSP/HttpOnly Cookieの防御を解説
- 送信ゼロ・防御教育（攻撃の練習ではない）
攻撃者
悪意ある入力者
サービス
サーバ / DB
サービス
サーバ / DB
別の利用者
何も知らない人
サービス
出力時エスケープ
別の利用者
安全に閲覧
STEP 1
※ イメージ図です。下の体験デモでは、scriptは安全に無効化された状態で「解釈の様子」だけを見られます。
🔒 このデモは安全です。 「危険な実装」パネルは、入力を sandbox 属性つきの隔離された枠 （allow-scripts を付けていません）に表示します。 だから <script> や onerror は ブラウザに無効化され、実行されません。「マークアップがどう解釈されるか」だけを安全に観察できます。
❌ 危険な実装（innerHTML 相当）
入力を“そのまま”HTMLとして解釈させる
⚠ 本番にsandboxが無ければ、ここでコードが実行されます。 このデモでは allow-scripts を付けていないため、scriptやonerrorは 無効化され実行されません（＝マークアップの解釈だけが見えます）。
✅ 安全な実装（エスケープ / textContent）
入力を“ただの文字”として表示する
エスケープ後のHTML（このまま埋めても安全）
⚖ これは攻撃の練習ではなく、開発者が「なぜ入力を信用してはいけないか」を学ぶための防御教育です。 実在のサイトや他人のサービスで、許可なくこうした入力を試す行為は不正アクセス禁止法などに触れるおそれがあります。 学習はこのページや、自分で用意した検証環境の中だけで行ってください。
やってはいけない
入力を信用してHTMLに入れる
- ✕element.innerHTML = userInput で、入力を生のHTMLとして描画。
- ✕テンプレートに値を“素通し”で埋め込む（自動エスケープを切る）。
- ✕URLや属性を検証せず href や on* に流す。
こうする
出力する瞬間に無害化する
- ✓element.textContent = userInput で、必ず「文字」として扱う。
- ✓HTMLに出すなら出力時エスケープ（< → <）。
- ✓フレームワークの自動エスケープを切らない。
XSSを防ぐ5つの守り
「入力は信用しない、出力で無害化する」が鉄則。
- 1
出力時エスケープ
HTMLに値を埋める瞬間に < > & " ' を実体参照へ変換。タグとして解釈されなくなり、ただの文字になります。埋める場所（HTML本文・属性・URL・JS・CSS）ごとに正しいエスケープを使うのが要点。
- 2
textContent / DOM API を使う
innerHTML ではなく textContent や setAttribute で値を入れれば、ブラウザが自動で「文字」として扱い、コードとして実行しません。そもそもHTMLを文字列連結で組み立てないのが安全。
- 3
CSP（Content-Security-Policy）
「どこのスクリプトを実行してよいか」をHTTPヘッダで宣言する保険。script-src 'self' などで、万一エスケープ漏れがあってもインラインスクリプトの実行をブラウザ側で止められます（多層防御）。
- 4
HttpOnly Cookie
セッションCookieに HttpOnly を付けると、JavaScriptから document.cookie で読めなくなります。仮にXSSが起きても、セッション乗っ取りの被害を小さくできます（Secure / SameSite も併用）。
- 5
フレームワークの自動エスケープ
React・Vue・Svelte・Astro などは、値の埋め込みを既定でエスケープします。だからこそ dangerouslySetInnerHTML や v-html のような「自動エスケープを切る入口」を安易に使わないことが大切。生HTMLが必要なときは DOMPurify などのサニタイザを通します。
🔒 このデモはすべてあなたのブラウザの中（JavaScript）で完結します。入力はサーバに送られません（送信ゼロ）。外部CDN・APIも使いません。「危険な実装」の表示は sandbox 付き iframe で隔離され、script は実行されません。
よくある質問
- Q. このデモを使うと自分の環境にウイルスが入りませんか？
- A. 入りません。入力は allow-scripts を付けない sandbox iframe に隔離され、scriptは実行されません。すべてブラウザ内で完結し送信もしません。
- Q. なぜ「危険な実装」パネルでもalert等が出ないのですか？
- A. sandbox属性（allow-scripts無し）でスクリプト実行がブラウザに禁じられているためです。本番でsandboxが無ければ、同じ入力でコードが実行されてしまいます。
- Q. XSS（クロスサイトスクリプティング）とは何ですか？
- A. 攻撃者の入力が無害化されないままHTMLに混ざり、別の利用者のブラウザで意図しないコードが実行される脆弱性です。
- Q. 格納型・反射型・DOM型の違いは？
- A. 格納型はサーバに保存され他者の画面で発火、反射型はリクエストに含めた入力がその場で返り発火、DOM型はクライアントのJSが入力を危険に扱うことで発火します。
- Q. 一番確実な防ぎ方は？
- A. 出力時にエスケープし、innerHTMLでなくtextContent/DOM APIで値を入れること。フレームワークの自動エスケープを切らないことが基本です。CSPやHttpOnly Cookieは被害を抑える保険（多層防御）です。
- Q. 学んだ手法を実在のサイトで試してよいですか？
- A. いけません。許可のない検証は不正アクセス禁止法等に触れるおそれがあります。学習はこのページや自分の検証環境内に限ってください。
入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。
RELATED TOOLS
続けて整える
