HttpOnlyフラグのない安全なCookieは問題ですか？
セキュアフラグ付きのCookieはHTTPS接続を介して送信する必要があることを理解しています。また、これらのCookieは敵から保護される必要があります（プライベートCookie）。したがって、XSSを防ぐために、この種のプライベートCookieにHttpOnlyフラグを設定することが重要です。
セキュアフラグが付いているがHttpOnlyフラグが付いていないプライベートCookieは問題ですか？
本質的に、私はHttpOnlyフラグをセキュアフラグ付きのCookieに追加する必要があると思います。
secureフラグは、Cookieの設定と送信が安全な方法（つまり、https）でのみ行われることを保証します。 httpのオプションがある場合、セキュアフラグはそのCookieの送信を防止する必要があります。したがって、httpを使用するか、httpにフォールバックするオプションがある場合、安全なフラグが欠落していることが問題になります。
httpOnlyは、スクリプト言語（つまり、javascript）が（document.cookieなどを介して）cookie値を取得できないようにします。これを取得する唯一の方法は、http要求ヘッダーと応答ヘッダーを使用することです。したがって、欠落しているhttpOnlyとXSSの脆弱性の組み合わせは、盗まれたセッショントークンのレシピです。
セッショントークンにはhttpOnlyおよびセキュアフラグを設定するのが最適です。他のクッキーは、それがどれほど敏感で、何のために使われるかによります。
これらの2つのフラグは、2つの完全に異なる攻撃ベクトルを軽減します。
- HttpOnly-成功したクロスサイトスクリプティング攻撃を軽減します。
- 安全-中間者攻撃を軽減します。
一方が他方のないということは、その特定のベクトルのみを軽減したということです。つまり、防御する脅威の種類によって異なります。 Secureが設定されていない場合でも、HttpOnlyは便利です。中間者も適切に配置する必要があるためです（ローカルネットワークなど）。クロスサイトスクリプティング攻撃者はインターネット上のどこにでもいる可能性があるため、これ自体を緩和することは依然として有用です。
注意として、これらのフラグは「多層防御」対策のみである必要があります。 SecureフラグよりもHSTSを推奨し、HttpOnlyフラグよりも適切な出力エンコードを使用したタイトなコンテンツセキュリティポリシーをいつでも作成することをお勧めします。
HTTPonly cookieフラグは、クライアント側のスクリプトがcookie値にアクセスできないようにするため、セッションcookieのセキュリティ制御として機能します。これは、攻撃者が正規のHTMLページに悪意のあるスクリプトを挿入した場合に効果的です。 HTTPonlyフラグは、悪意のあるスクリプトがセッションCookieにアクセスすることを防ぎ、 セッションハイジャック を防ぎます。
このフラグはリスクを特定のレベルに減らすだけであり、スクリプトインジェクションの脆弱性が存在する場合でも、前述のように複数の方法で悪用される可能性があることに注意してください here
「httponly」フラグは、ブラウザのクライアント側スクリプト（JS、TS）を介してこのCookieにアクセスできないようにします。ページにXSSの脆弱性があると、攻撃者は「document.cookie」変数にアクセスできなくなります。
だからあなたの質問に答える-はい。これは問題になる可能性があります。
SSLで保護されたページは、考えられるXSS攻撃から保護せず、この種のCookieを取得する機会を攻撃者に与えます。