なぜ混乱しやすいのか
CORS と Cookie の話は混乱しやすいです。理由は、似た言葉が別の基準で使われるからです。
- CORS は origin を見る
- SameSite Cookie は site を見る
- サードパーティCookieは文脈を見る
この3つを分けると、SPAとAPIの認証設計が理解しやすくなります。
origin とは
origin は、次の3つの組み合わせです。
- スキーム
- ホスト
- ポート
たとえば、https://app.example.com と https://api.example.com はホストが違うため、別originです。
| URL | origin |
|---|---|
https://app.example.com | https://app.example.com:443 |
https://api.example.com | https://api.example.com:443 |
http://app.example.com | http://app.example.com:80 |
JavaScriptの fetch で別originへアクセスすると、CORSの制約が関係します。
CORS とは
CORS は Cross-Origin Resource Sharing の略です。
ブラウザは、JavaScriptから別originへ自由にアクセスできないようにしています。CORSは、サーバが「このoriginからなら読んでよい」と許可を出す仕組みです。
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Cookieなどの認証情報を含むクロスオリジンリクエストでは、サーバ側の許可とクライアント側の設定が必要です。
fetch("https://api.example.com/me", {
credentials: "include",
});
site とは
site は、CookieのSameSite判定で重要です。ざっくり言うと、登録可能ドメインを中心に見ます。
たとえば、次の2つはoriginは違いますが、同一siteとして扱われる場面があります。
https://app.example.comhttps://api.example.com
どちらも example.com 配下だからです。
| 通信 | cross-origin | cross-site |
|---|---|---|
app.example.com -> api.example.com | Yes | No |
app.example.com -> auth0.com | Yes | Yes |
app.example.com -> example.com | Yesの場合あり | No |
ポイント: app と api がサブドメイン違いなら cross-origin ですが、same-site です。CORSは必要でも、サードパーティCookie問題とは別です。
サードパーティ Cookie とは
サードパーティCookieは、ユーザーが見ているサイトとは別のsiteのCookieが使われる場面で問題になります。
たとえば、app.example.com を見ているページの中で、auth-provider.com のiframeやリクエストがCookieを使う場合です。
これは広告トラッキングや外部IdP連携で重要なテーマになりました。ブラウザ各社はプライバシー保護のため、サードパーティCookieを制限してきました。
SPA + API の典型パターン
SPAでは、次のような構成があります。
| 構成 | CORS | Cookie規制の影響 |
|---|---|---|
app.example.com -> api.example.com | 必要 | same-siteなら比較的小さい |
app.example.com -> api.other.com | 必要 | cross-siteなので強く影響 |
app.example.com -> auth0.com | 必要 | 外部IdPとして影響を受けやすい |
「クロスオリジンだからCookieが必ず使えない」わけではありません。同一site内のサブドメイン構成なら、Cookieセッションは今でも現実的です。
CORS はセキュリティ境界の一部でしかない
CORSは、ブラウザがJavaScriptにレスポンスを読ませるかどうかを制御します。
しかし、CSRF対策そのものではありません。CORSで許可していないから状態変更リクエストが絶対に届かない、とは考えない方が安全です。
状態変更APIでは、CSRFトークン、SameSite、Origin検証などを組み合わせます。
BFF で何が変わるか
BFFを置くと、ブラウザはBFFだけを呼びます。
Browser -> BFF -> API
ブラウザとBFFを同一originまたはsame-siteに寄せれば、Cookieセッションを扱いやすくなります。外部APIや外部IdPとのトークン処理は、BFFがサーバ側で担当します。
これにより、ブラウザが外部APIのアクセストークンを直接持つ必要が減ります。
まとめ
CORS、site、third-party cookie は別の概念です。
- CORS は origin を見る
- SameSite Cookie は site を見る
- サードパーティCookieは閲覧中サイトとの関係を見る
- サブドメイン違いは cross-origin だが same-site の場合がある
- 外部IdPや別site SaaS連携ではCookie規制の影響を受けやすい
- BFFはブラウザとの境界をsame-siteに寄せやすい
参考リソース
- 公式ドキュメント - CORS と Cookie - オリジン・サイト・サードパーティ Cookie の違い を確認するための一次情報
