[https://www.youtube.com/watch?v=tn7PqBKn-KE:embed:cite]
Web開発において避けて通れないCORS（Cross-Origin Resource Sharing）の仕組みとセキュリティ対策を、ストーリー形式のスライド資料を用いて徹底解説します。なぜ「同一オリジンポリシー」によってAPI通信がブロックされるのか、かつての回避策「JSONP」がなぜ危険なのか、そして現代の標準であるCORSをどのように設定すればCookieを含む認証情報を安全にやり取りできるのかを学びます,,。 Webブラウザにはセキュリティの根幹となる同一オリジンポリシーというルールが存在し、URLの構成要素であるスキーム、FQDN、ポート番号が完全に一致しない限り、異なるオリジンへのリソースアクセスは原則として禁止されています。かつてはこの制限をすり抜ける裏技として、scriptタグが外部ソースを読み込める性質を利用したJSONPという手法が使われていましたが、これはアクセス元を制限できないため、悪意あるサイトを閲覧しただけでログイン済みユーザーの個人情報が流出してしまう危険性があり、現代の開発現場では推奨されない過去の遺物となっています,,。これに代わる正当な技術がCORSであり、サーバーがAccess-Control-Allow-OriginなどのHTTPヘッダを含めることで、ブラウザに対して特定のオリジンからのデータ受け取りを許可する仕組みです,。この通信プロセスでは、実際のデータを取得するGETやPOSTリクエストを送る前に、ブラウザが自動的にOPTIONSメソッドを用いたプリフライトリクエストを送信し、サーバーに対して「このメソッドやヘッダを送信しても安全か」という事前確認を行う挙動が含まれます。特にECサイトや会員サイトでCookieなどの資格情報（Credentials）を含めて通信を行う場合は注意が必要で、サーバー側でAccess-Control-Allow-Credentialsをtrueに設定する必要がありますが、この際に許可オリジンをワイルドカード（*）に設定することは仕様上禁止されており、実装時に絶対に踏んではいけないトラップとして知られています,。したがって、複数の異なるドメインを持つサービスと連携させたい場合、ヘッダには一つのオリジンしか記述できないという制約を乗り越えるために、サーバー側でリクエスト元のオリジンを検証し、信頼できるリスト（ホワイトリスト）にある場合のみその値を動的にヘッダへセットする動的ホワイトリスト方式の実装が不可欠となります,。SPA（シングルページアプリケーション）やマイクロサービスアーキテクチャが主流の現代において、CORSは単に通信を遮断する壁ではなく、正しい相手と正しくつながるための重要な技術であり、Varyヘッダの適切な利用やメソッドの制限などを含めたセキュアな実装要件を正しく理解することが求められます,。
