HTMLタグ、つまりtextarea要素の使用が許可されている場合、悪意のあるユーザーがXSS攻撃を実行しないようにするにはどうすればよいですか？私はすべてのタグを取り除くか、エスケープしないので、{{ }}を使用することはできません。Laravel：HTMLタグが許可されている場合、XSSに対するユーザー入力のサニタイズ
ところで、{{ }}でも良いアイデアではない別の危険な状況があります。 this linkを考慮してください。ユーザーにHTMLタグを使用させ、XSS攻撃を行わないようにする方法はありますか？
XSSを防止しようとすると、クライアントサイドのHTMLエディタがおそらく最大の課題です。多くのサードパーティのエディタコンポーネントは実際にはそうしていません。
多くのシナリオで実際にうまく機能する1つのアプローチは、サニタイズです。あなたは入力としてhtmlを持ち、すべてのjavascriptを削除することになっていることを除いて、出力とほぼ同じhtmlを持つサニタイザライブラリを利用することができます。 1つの例はHTML Purifierです。これはサーバー側でこれを行います。
多くの人が、これを行うための正しい場所はサーバー側だと主張します。しかし、その中には、あなたのユースケースに当てはまるかもしれないし、まったく適用されないかもしれない1つの警告が時にはあります。クライアントサイドのHTMLエディタにプレビューがある場合は、DOM XSSを防ぐためにサニタイズする必要があり、プレビューはサーバに送信されないことがあります（編集したコンテンツは、サーバラウンドトリップなしでクライアントに表示されます）。これはリスクが低いXSSですが、間違いなく予防する必要があります。サーバーサイドのサニタイズはほとんど役に立ちません。
クライアント側のサニタイザは、サーバー側のサニタイザの代わりに、またはサーバー側のサニタイザの代わりに使用できます。その1つの例は、Google Cajaのクライアントサイドのサニタイザです（これははるかに大きなプロジェクトですが、私は彼らのsanitizer in Javascriptについてのみ話しています）。またはクライアントに別の例としてDOMPurifyがあります。これらは、実際に表示する前にコードをサニタイズして、XSSを効果的に排除するために、クライアントサイドのHTMLエディタコンポーネントにフックすることができます。
サニタイズのリスクは、サニタイザーが何かを逃してしまい、XSSの攻撃ベクトルが通過できなくなることです。これは、基本的には、信頼の事で、多くの人々は、例えばカハを使用し、それは、Googleが開発したので、あなたはそれが合理的に良いことだということ一部保証を有することができます。
異なる起点のHTMLコンテンツを提供し、その起源にXSSのリスクを受け入れるか、カスタムマークアップを慎重に使用する方法があるかもしれません（あなたのために十分なのかどうかは、あなたの正確なシナリオ、リスクの食欲などによって異なります）それをXSSフリーhtmlに変換するなど）、ほとんどの用途ではサニタイズが最も効果的です。