esc_urlを使用する理由

これは私のコーディングを難しくします。Wordpress codexは、セキュリティについて漠然と話すことでesc_urlの使用を理由としています。しかし、それは本当にトラブルに値するのでしょうか？

たとえば、次を使用することによる重要で実用的なセキュリティ上の利点は何ですか

<?php echo esc_url( home_url( '/' ) ); ?>

の代わりに

<?php echo home_url() ?>

PS：私はテーマ開発について話しているのではなく、特定のサイトについて話している。

データ検証のドキュメントを確認すると、関数について次のように述べられています。

URLをサニタイズするとき（テキストノード、属性ノード、またはその他の場所）は常にesc_urlを使用します。提供されているホワイトリストプロトコル[...]のいずれもないURLを拒否し、無効な文字を削除し、危険な文字を削除します。

そこには、実用的なセキュリティ上の利点があります。有効なプロトコル、あいまいな文字はありません。

必要性についての答えはしっかりとイエスです。出力のエスケープは、最も基本的なセキュリティ対策です。

まあ、すべてのユーザー入力を無害化する必要があります...注入するURLがユーザー入力ではない場合（完全に信頼できる人によるサイト設定、ハードコードされた値など）、esc-urlから解放されます。

しかし、もし私があなたのサイトにそのURLを注入できれば、jsコードやリダイレクトコードを簡単に注入できます...場合によってはサーバー側のコードも注入できます。

これにより、セッションの乗っ取りや、ユーザーアカウントの盗難やその他の悪いオプションにつながる可能性があります。

編集：

あなたの例esc_url( home_url( '/' ) );
では、それはセミハードコードされた値で動作しました！したがってesc_url、削除することができます。
とはいえ、脅威が存在する場合と存在しない場合の違いがわからず、通常、すべての値に対してesc_url（）を保持することをお勧めする理由はまだわかりません。

もう1つ頭に留めておく必要があるの esc_url()は、<a href="SANITIZE_THIS_URL">your_text</a>.htmlのようなものです。リンクのhref属性や画像要素のsrc属性など、HTML出力でURLを使用する場合は、を使用する必要がありますesc_url()。

esc_url_raw()クリーンなURLが必要だが、HTMLエンティティがエンコードされないようにしたい他の場合です。したがって、HTML以外の使用（DB、リダイレクト）ではこれを使用します。

このesc_url_raw()関数はとほとんど同じようesc_url()に動作しますが、エンティティをデコードしません。つまり、＆を＆＃038に置き換えないなどです。マークが指摘したように、それを使用しても安全だesc_url_raw()などについて詳細はwp_remote_get（）」 `として、データベースクエリ、リダイレクトおよびHTTP関数で）（esc_url_raw

esc_urlは、有効なHTMLを生成するために使用されます（入力を無害化するためではありません）。これは、出力するものがそのコンテキストで有効なHTMLであるかどうかが100％わからない場合に使用してください。