XSS対策の基本：WordPressで表示する文字を安全に扱う

管理画面も含めて表示先を探す

XSSは、サイトが表示する内容へ意図しないスクリプトなどが混入し、訪問者のブラウザーで動作する問題です。公開ページのほか、申請内容を確認する管理画面でも影響が生じる場合があります。

登録フォーム、プロフィール、レビュー、カスタム項目など、外部から届く値がどこに表示されるか記録します。例えば申請紹介文が一覧、詳細、編集画面の三か所に現れるなら、それぞれの出力処理を調べます。

WordPressはHTML本文に置く文字、属性に置く文字、リンク先URLなど、それぞれの場面に合わせた関数を用意しています。本文用の処理をURLや属性にも機械的に流用せず、実際の出力箇所に適した処理を選びます。

装飾を許可する場合は、どのHTMLを許可するかを明確にします。入力時に保存形式を整えたデータであっても、出力する直前にその文脈に合った処理が必要です。管理者が入力した値や既存データも自動的に安全とは限りません。

入力検証は、値が選択肢や文字数など業務上の条件を満たすかを確かめる作業です。出力時の処理は、その値を置く場所で文字が想定外の意味を持たないようにする作業です。どちらか一方を行えば他方が不要になるわけではありません。

仮にジャンル名を登録済みの選択肢から受け取っても、保存後の表示先で適切に扱う必要があります。外部APIから取得した商品名や過去の登録値も含め、データの入口と出口を対応付けて確認しましょう。

検証環境で日本語や記号を含む通常の入力を保存し、公開一覧、詳細、管理画面で期待どおり表示されるかを調べます。危険な入力の試験は許可された環境で担当者が行い、実際の利用者データに影響させないようにします。

許可した装飾まで消えていないか、リンク先が壊れていないかも確認します。修正の場所と確認日を記録し、テーマやプラグインを更新したときも同じ表示箇所を再確認できるようにしておきます。

表示先の台帳には「項目名／入力元／保存場所／表示テンプレート／出力文脈／確認者」を記入します。たとえば紹介先URLなら、編集画面の入力欄、管理一覧、公開カード、リンク先の属性まで追います。

文字が安全に扱われても、リンク先そのものが許可した形式かという検証は別です。URL形式の検証、出力時の扱い、外部リンクの遷移確認を分け、何を確認したのかが後から分かるようにしましょう。

公開記事に使う情報と管理画面だけに出す情報が異なる場合も、どちらも利用者へ表示されるデータであることに変わりはありません。見た目だけの確認に加え、開発担当者にテンプレートと出力処理をレビューしてもらいましょう。

確認日：2026-11-02。提供条件や仕様は変更される場合があります。