CSPからreflected-xssディレクティブを削除した本当の理由は何ですか？
過去にヒューリスティックスに基づく反映されたXSSの検出と防止を有効にするようにブラウザーに指示するためにサーバーが設定できる2つの応答ヘッダーがありました。
- X-XSS保護：1;モード=ブロック
- コンテンツ-セキュリティ-ポリシー：reflected-xss
X-XSS保護
このヘッダー MDNによる ;
- Chromeには「 XSS監査を廃止および削除する意図 」があります
- Firefoxはそうではなく、 X-XSS-Protectionを実装しません
- エッジは XSSフィルターを廃止
コンテンツセキュリティポリシー
CSP 2.0および3.0では、reflected-xssディレクティブが指定されています。これはCSP 2.0のドラフトに含まれており、最近のほとんどのブラウザーはそれをサポートしていない（ Chrome ）か、ディレクティブについての言及がありません。
- 最近のブラウザには、サーバーヘッダーによって制御できるヒューリスティックベースのXSS保護がないというのが公正な仮定でしょうか。
- 広く採用されている他のXSS保護ヘッダーはありますか？
あなたが提供するMozillaリンクはあなたの質問に答えるのに十分であると思います（スレッドから順序が乱れているので、私はより良いストーリーを伝えることができます） ：
Firefoxは、ここで説明されているような（おそらく（より高価な）アルゴリズム）を使用した方がよいでしょう（ http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf ）。 HTTPトラフィックの代わりにスクリプトの実行に割り込むと（このホワイトペーパーのように）、小さい文字列が一致するようになります。これにより、このアルゴリズムで大きなスローダウンが発生することはありません。
したがって、このヒューリスティックなXSS保護アルゴリズムは、URLとページコンテンツ間の文字列比較の山に依存しているため、ブラウザのCPUフットプリントを低く抑えたいと考える人には嫌われます。
ブラウザーとWebサイトがCSPを採用するのを待つ間、反映されたXSS攻撃からの保護はMozillaへの便利な追加になるでしょう。実際、CSPを提供しないWebサイトのデフォルトのCSPとして実装できます。
ここでの意味は、ブラウザで実行されている一般的なヒューリスティックは、特定のWebサイトの開発者よりも厳密に効果が低く、適切に実装されたCSPを提供して、ページで実行できるコンテンツを指定することです。
数多くの議論があり、2016年後半の最新の議論であり、Firefoxが組み込みの機能を提供するのに現在努力する価値がないという結論に達しました。
XSSフィルターは、最近ますます普及している格納された（永続的な）XSSまたはDOM XSSから保護できません。
XSSフィルターは、非常に注意深くアクティブに保守されないと、セキュリティホールが発生しやすくなります。限られた価値しか提供しない機能について、セキュリティエンジニアリングの時間を正当化することは困難です。
最後に、NoScriptにはユーザーが使用できるXSSフィルターがあります。
これは、XSSフィルターは、結局のところ、それほど効果的ではないことを物語っています。