APIを保護する認証トークンのHttpOnly Cookieまたはヘッダーフィールドを保護しますか？
保護するAPIがあります。このAPIの2種類のコンシューマーが存在する可能性があります-独自のシングルページアプリケーションと、それと統合するサードパーティのサービス。
REST APIの場合、一般にCookieは好まれません。ヘッダーフィールドを使用することをお勧めします。おそらくこれは単なる慣例です。
セキュアCookieは、SPAで認証トークンを保持するためのより良い場所です。クロスサイトスクリプト攻撃によって取得されるのを防ぎます。また、SPAが新しいウィンドウ/タブを開いた場合、sessionStorageは逆方向に流れないため、ユーザーは再度ログインする必要があります。 localStorageを使用することはできますが、永続化するため、そこに認証トークンを保持することはお勧めできません。
サーバー側の認証フィルターにCookieまたはヘッダーフィールドのいずれかを許可する必要がありますか？最初にCookieを試してみて、そこにない場合はヘッダーフィールドを試してください。 CookieはSPAによって使用され、ヘッダーフィールドは他のAPIコンシューマーによって使用されます。または、認証トークンを送信する方法を1つだけにする方が良いでしょうか？
適切に使用しても、Cookieやヘッダーのセキュリティに大きな違いはないと思います。
Cookieはサーバーの状態を維持するためのものです。したがって、セッションを開始するログイン呼び出しがある場合、Cookieは意味があります。 APIの外部で配布されるAPIトークンを使用する場合、Cookieは意味がありません。
最後に、Cookieもヘッダーで送信されるため、Cookieの送信方法にはほとんど違いがありません。違いは、ブラウザーがCookieを処理する方法です。
- CookieをHttpOnlyとして設定して、JavaScriptからアクセスできないようにすることができます。
- Cookieは、ブラウザによるすべてのリクエストに含まれています。
HttpOnlyはXSSに対する保護を提供します。ただし、攻撃者は、XSSを取得したときに、Cookieを取得していなくても、好きな方法でAPIを呼び出すことができます。
そのCookieがすべてのリクエストに含まれていると、クロスサイトリクエストフォージェリ（CSRF）に対して脆弱になります。別のWebページがAPIへのリクエストをトリガーする可能性があり、Cookieはデフォルトで含まれています。
SPAでは、トークンを格納する代わりにJavaScript変数を使用します。これは、タブが開いている間のみ保持され、変数のスコープが制限されている場合はXSSに対して保護される可能性があります。
トークンをlocalStorageに保存すると、アプリケーションが閉じられたときにlocalStorageがクリアされないため、トークンが永久に保持されます。ただし、サーバー上のトークンを期限切れにすることができるため、これはそれほど悪くはありません。トークンがlocalStorageに保持されていたためにしばらくしてから公開されたとしても、トークンは有効ではなくなります。
2つのトークンを使用する可能性もあります。1つはCookieで、もう1つはヘッダーで使用します。 APIを正常に使用するには、両方のトークンが必要です。 CookieはHttpOnlyであるため、XSSから保護されます。ヘッダーはすべてのリクエストで送信されるわけではないため、CSRFから保護されます。
ご説明のとおり、認証情報はCookieでのみ送信することをお勧めします。あなたが述べたように、これはあなたのシングルページアプリケーションからのユーザーの認証トークンの漏洩を防ぎます。
追加のボーナスとして、認証トークンをCookieとして持つと、チェックする場所が1つしかないため、認証フィルターのロジックが簡素化されます。
SPAにXSSの欠陥がある場合でも、攻撃者のJavaScriptは、認証トークンにCookieを使用するかヘッダーを使用するかに関係なく、ユーザーになりすましてリクエストを発行できることに注意してください。したがって、出力を無害化してください:-)