CORSとは何か? クロスオリジンのブラウザセキュリティ

CORS(クロスオリジンリソース共有)は、あるオリジンのWebページが別のオリジンのAPIを呼び出せるかどうかを制御するブラウザのセキュリティ機構です。

ブラウザは、サーバーがCORSヘッダーで明示的に許可しない限り、ページが別のオリジンのレスポンスを自由に読み取ることをブロックします。これはユーザーを保護しますが、deploy後にフロントエンドがAPIに到達できないとき、開発者を驚かせます。CORSはブラウザによって強制されるため、サーバー間のCI呼び出しではなく、フロントエンドやend-to-endのテストで現れます。

何がクロスオリジンとみなされるか

オリジンとは、スキーム、ホスト、ポートの組み合わせです。app.example.comからapi.example.comへのリクエストは、同じ親ドメインの下であってもホストが異なるためクロスオリジンです。

サーバーが許可を選択する

サーバーはAccess-Control-Allow-Originのようなレスポンスヘッダーでアクセスを付与します。正しいヘッダーがなければ、サーバーが正常に応答したとしても、ブラウザはページがレスポンスを読み取ることをブロックします。

preflightリクエスト

単純でないリクエストの場合、ブラウザはOPTIONSのpreflightを送信します。
サーバーは許可されたメソッドとヘッダーでそれに応答する必要があります。
preflightが失敗すると、実際のリクエストが完全にブロックされます。

なぜdeploy後に驚かされるのか

新しいドメインにdeployされたフロントエンドが、まだそのオリジンをリストしていないAPIを呼び出すと、リクエストがブロックされます。新しいオリジンを含めるようにAPIのCORS設定を更新すれば修正されます。

end-to-endテストにおけるCORS

CIでのブラウザベースのテストは、実際のCORSの挙動を検証します。preflightの失敗やallow-originヘッダーの欠如は、テスト実行でブロックされたネットワークリクエストとして現れ、ユーザーが直面するものを反映します。

設定であって揺らぎではない

CORSの失敗は決定的です。同じ欠けたヘッダーが、修正されるまですべてのリクエストをブロックします。Latchkeyのrunnerは真に一時的なネットワーク障害をretryしますが、CORSの設定ミスはAPI側のconfig修正であり、retryで解決するものではありません。

重要なポイント

CORSはクロスオリジンのAPIアクセスを統制するブラウザのルールであり、クライアント側で強制されます。
サーバーはallow-originヘッダーを送信し、preflightリクエストに応答する必要があります。
CORSの失敗は決定的な設定であり、一時的なネットワークの揺らぎではありません。