シークレット/プライベートブラウジングはXSS攻撃を防ぎますか？
シークレット/プライベートブラウジングセッションを開始するとき、他のブラウジングプロファイルからのCookieは存在しないはずです。たとえば、メインのブラウジングプロファイルのサイトにログインしている場合、新しいプライベートブラウジングセッションを開始すると、同じサイトにはログインしません（Cookieは引き継がれません）。それが新しいプライベートブラウジングセッションであると想定すると、既存のCookieや機密情報を入手できないはずです。
これには、盗む機密データがないため、XSS攻撃を防止または無効化するという副作用もありますか？または、これは誤った安心感ですか？
XSS攻撃は主にCookieに関するものではありません。機密データを盗むことも目的ではありません。代わりに、訪問したサイトのコンテキスト内でクライアント側で攻撃者が制御するコードを実行することです。このコードによってどのような害が発生する可能性があるかは、実際のサイトとコンテキストによって異なります。
プライベートブラウジングセッションを使用しても、XSS自体を防ぐことはできませんが、XSSが何を害するかという影響を制限する可能性があります。それでも害を及ぼす可能性はありますが、これは、アクセスする特定のコンテキストとサイトによって異なります。
主に2種類のXSS攻撃があります：永続的でアドホックです。
プライベートブラウジングセッションは、アドホックXSS攻撃から保護しますが、永続的な攻撃からは保護しません。
永続的なXSSは、攻撃者が機密ページのどこかにスクリプトコードを挿入することによって機能します。これは、プラットフォームで準備されたメッセージを送信するか、機密ページのストレージにデータを注入する他の方法で実行できます。機密ページにログインして一部のデータを表示すると、挿入されたデータがサーバーによって読み込まれ、ブラウザーに転送され、サイトが脆弱な場合に実行されます。例としては、オンラインバンキングトランザクションでの準備済みメッセージがあります。攻撃者は実際のトランザクションを送信し、メッセージ部分には有害なスクリプトが含まれます。他のページは関係しないので、これから身を守ることはできません。ページの所有者だけができます。
アドホックXSSは、インジェクションデータを含む準備されたリンクをクリックすることで機能します。このようなリンクは、挿入されたスクリプトがリンクの一部であるhttps://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script>のようになります。攻撃者はあなたにこのリンクをクリックさせようとするか、用意された自分のページからJavaScriptを介してバックグラウンドで実行しようとします。したがって、メールリンクと信頼できないページを別のセッションで開いた場合、シークレットセッションで機密ページにログインしていないため、機密ページのユーザーアカウントはこの種の攻撃から安全になります。そのため、XSSは引き続き実行される可能性がありますが、機密性の高いページで自分のアカウントに害を及ぼすことはありません。
Steffenがすでに述べたように、XSS（crossサイトスクリプティング攻撃）は、定義上onlyでCookieを処理しません。誰かがDBにアクセスし、特定のWebページで実行できるスクリプトタグを含む特定のフィールドを編集すると、XSS攻撃を実行できます。
それは単に、誰かがあなたがアクセスしているページのブラウザでスクリプトを実行して、あなたから情報（おそらくCookie）を取得したり、DOMを調整して、たとえば支払いボタンを彼の不完全なWebサイトにリンクしたりしてあなたを欺くことを意味します。