jQuery（またはJavascript）に関して、人がFacebook、Twitter、またはブログにコメントを投稿すると、舞台裏で何が起こりますか？
たとえば、最初にテキストをサニタイズしてから、実際のリンクにURLをパターンマッチさせますか？バックエンドでいくつかのチェックを行うことに加えて、クライアント側がチェックする必要がある他の懸念事項はありますか？
URLをリンクに変換するための正規表現をいくつか見つけましたが、より良い解決策があるかどうかはわかりません。
問題に頭を悩ませようとしていますが、どこから始めればよいのかわからないのです。あなたが提供できるどんなガイダンスも大歓迎です！
これは（私の意見では）意見の問題なので、この回答をCWします。インターネットの善意の市民としての私の意見は次のとおりです。
ポイント1に関しては、上記のポイント2を無視しているため、防御的なサニタイズは誤った方向に進んでいると思います。悪意のある入力から防御している環境がわからないと、入力アルファベットを大幅に制限せずに実際にサニタイズすることはできません。自分自身と戦っている可能性があります。これは、正当なユーザーがアカウントに保持したいデータを使用して実行できることを不必要に制限するため、ユーザーに対して敵対的です。「コメント」、「ニックネーム」、「メモ」の各フィールドに、XML、SQL、またはその他の言語の特殊文字のような文字を含めたいと誰が言いますか？入力をフィルタリングする意味的な理由がない場合、なぜそれをユーザーに行うのですか？
ポイント2は本当にこれの核心です。サーバー側のコード（またはクライアント側のコード）は、疑うことを知らない解釈環境に直接渡すことができるため、ユーザー入力は危険な場合があります。この環境では、それぞれの異なる環境にとって重要なメタ文字が予期しない動作を引き起こす可能性があります。手つかずのユーザー入力をクエリテンプレートに直接貼り付けてSQLに直接渡すと、悪意のあるユーザーが引用符などの特殊なSQLメタ文字を使用して、絶対に望まない方法でデータベースを制御する可能性があります。しかし、それだけでは、私の名前が「オー・ヘンリー」であると私があなたに言うのを妨げる理由はありません。
ポイント2の重要な問題は、多くの異なる解釈環境があり、ユーザー入力によってもたらされる脅威に関しては、それぞれが完全に異なることです。いくつか挙げてみましょう。
ここで重要な点は、これらの環境を不正な入力や悪意のある入力から保護するために必要な正確な手法は、人によって大きく異なるということです。SQLサーバーを悪意のある引用符から保護することは、HTMLまたはJavaScriptでそれらの引用符を保護することとはまったく異なる問題です（これらは両方とも完全に異なることに注意してください）。
結論：したがって、私の意見では、不正な入力や悪意のある入力の可能性を心配する場合の適切な注意の焦点は、ユーザーデータを読み取るのではなく、書き込むプロセスです。ユーザー提供データの各フラグメントは、各解釈環境と連携してソフトウェアによって使用されるため、「引用」または「エスケープ」操作を実行する必要があり、ターゲット環境に固有の操作である必要があります。それがどの程度正確に配置されているかは、場所によって異なる場合があります。たとえば、従来のSQLでは、プリペアドステートメントを使用しますが、プリペアドステートメントの欠陥により、そのアプローチが困難になる場合があります。HTMLを吐き出すとき、ほとんどのサーバー側フレームワークには、エンティティ表記でエスケープするHTMLまたはXML用のあらゆる種類の組み込みフックがあります（&にとって "＆"）。現在、Javascriptで物事を保護する最も簡単な方法は、JSONシリアライザーを利用することですが、もちろん他の方法もあります。