OWASP JWTチートシートで言及されているトークンサイドジャッキング防止の有用性
私はOWASPのJWTチートシートの「トークンサイドジャッキング」を読んでいました（ https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.html#token-sidejacking ）
現時点では、推奨される予防策が実際に問題を解決する方法がわかりません。
解決策は、コンテキストを追加し、このコンテキスト（ランダムな値など）をCookieとして送信することと、JWTの一部（そしてハッシュ化）として送信することです。
ただし、攻撃者がXSS攻撃を実行してJWTを盗み、sessionStorageにアクセスできる場合、攻撃者はXHRリクエストも送信できるため、Cookieが自動的に送信されます。攻撃者がネットワークトラフィックを盗聴できる場合、攻撃者はCookie値も持っています。これが機能する場所を考えることができる唯一のケースは、攻撃者が何らかの種類のログにアクセスでき、JWTが保存されている場合ですが、これは別の脆弱性（またはそれ以上）になります。
私は何を取りこぼしたか？ありがとう
攻撃者がネットワークトラフィックを盗聴できる場合、攻撃者はCookie値も持っています。
あなたは、攻撃者がネットワークトラフィックを盗聴し、なりすましを見つけたときに使用する攻撃について説明しています。
ほとんどのセキュリティアナリストは、TLS（つまりHTTPS）がこれに対する十分な保護であると考えています。トラフィックは、ブラウザーから、話しているWebサーバーへのすべての方法で暗号化されます（理論的には、リクエストがバウンスしてサイトのバックエンドインフラストラクチャ内でプレーンテキストで記録される可能性がありますが、サイトのバックエンドに入る必要がありますネットワーク）
私もあなたに同意する必要があります。そのアドバイスが実際に何でもするシナリオを考え出すのにも苦労しています。
攻撃者がJWTを傍受できれば、Cookieも取得できると思います。
悪意のあるJavaScriptをページに挿入し、ブラウザーのローカルストレージを読み取ることができる場合、GET/POSTを送信してCookieを自動的に添付することもできると思います。
攻撃者がXSS攻撃を実行してJWTを盗み、sessionStorageにアクセスできる場合、攻撃者はXHRリクエストも送信できるため、Cookieが自動的に送信されます
ソリューションは SameSite Cookieを使用します。それらは攻撃者のサーバーに送信されません。