CORS(Cross-Origin Resource Sharing)をエラーログから読み解く

本記事ではWebサイトを運用していると一度は遭遇するであろうCORS(Cross-Origin Resource Sharing)について、エラーログを読むことで取り敢えずどんなものかを知っておこうというスタンスで書いています。CORSはなかなか奥が深く、ここではCORSのイメージが伝わればと思っています。

例えば図1のような構成(WebサーバーがAPIサーバーからデータを取得)でCORS対策をしていない状態で「http://localhost:3000/」にブラウザからアクセスすると図2の赤字のようなエラーになってしまいます。

図1 : CORS構成図
図1 : 構成図
図2 : CORSエラーログ
図2 : CORSエラーログ

図2のエラーログを読むと、1文目にWebサーバーのオリジン(origin)「http://localhost:3000」からAPIサーバーのエンドポイント「http://localhost:8000/api/vi/test/」にアクセスしたらCORSポリシーによってブロックしたという内容が書かれています。2文目に「Access-Control-Allow-Origin」ヘッダーが存在していないとも書かれています。オリジンというのは下記をご参照ください。

上記のエラーは要は「Access-Control-Allow-Origin」ヘッダーが無い中でWebサーバーのオリジン「http://localhost:3000」とAPIサーバーのオリジン「http://localhost:8000」が異なるのでAPIサーバーへのアクセスをブロックしたということになります。

対策としてはエラーログにもある通り、「Access-Control-Allow-Origin」ヘッダーにオリジン「http://localhost:3000」を指定して安全なオリジンであることを保証してやる必要があります。

オリジンはRFC 6454 (The Web Origin Concept)に定義されていて、スキームとホストとポートの組み合わせになります。例えば「http://localhost:8000/api/vi/test/」であれば「http://localhost:8000」部分がオリジンを示す箇所にあたり「http」がスキーム、「localhost」がホスト、「8000」がポートということになります。
ちなみにスキームがhttpでポートが80であればポートは省略できるので、「http://localhost/」は「http://localhost:80/」と同一オリジンになります。同様にスキームがhttpsでポートが443のときもポートを省略できます。
sponsor