【入門編】 APIゲートウェイにおけるCORS(Cross-Origin Resource Sharing)制御 – Web APIアーキテクチャ・データ連携実践ガイド

「勝手に入ってこないで！」Webの用心棒、CORSの仕組みを郵便配達で理解する

こんにちは！ネットワークの世界にどっぷり浸かって十数年、パケットの呼吸音が聞こえる気がするインフラエンジニアの主筆です。

今日は、Web API開発の現場で避けては通れない、でも初学者が一度は頭を抱える「CORS（コルス）」という仕組みについてお話しします。

「APIを作ったのに、ブラウザから叩くとエラーになる…」
「Access-Control-Allow-Origin って何なの？」

そんなモヤモヤを、今日は「郵便配達」に例えてスッキリ解消していきましょう！

—

1. CORSは「Web界の厳重なマンション管理人」

まず、なぜCORSなんて面倒な仕組みがあるのでしょうか。

皆さんが住んでいるマンションを想像してください。自分の部屋（オリジンA）から、隣の部屋（オリジンB）に「ちょっとこの書類（データ）を勝手にコピーして持っていって！」と頼むのは、セキュリティ的に怖すぎますよね。

ブラウザも同じです。「違う場所から来たスクリプトが、勝手にAPIのデータを盗み見たり、書き換えたりできないようにする」というルールが、このCORS（Cross-Origin Resource Sharing：オリジン間リソース共有）なんです。

2. プリフライトリクエスト＝「事前の身分証チェック」

ブラウザがAPIにリクエストを送る際、いきなり本番のデータを送るわけではありません。まずは「プリフライトリクエスト」という「お伺い」を送ります。

これは、郵便配達員が玄関先でインターホンを鳴らすようなもの。

ブラウザ（配達員）: 「すみません、このAPIに『POST』でデータを送りたいんですが、このオリジン（送信元）から送っても良いですか？」
APIゲートウェイ（管理人）: 「ちょっと待って。許可リストを確認するから…OK、いいよ（OPTIONSメソッドへの応答）」

この「いいよ」という許可をもらって初めて、本番のデータが送れるようになるのです。この「いいよ」と言ってもらうための確認作業こそが、OPTIONSメソッドを使ったプリフライトリクエストの正体です。

—

3. APIゲートウェイでCORSを制御しよう

APIゲートウェイは、この「マンションの管理人室」にあたります。ここで適切にヘッダー（許可証）を付与してあげれば、スムーズな連携が可能になります。

例えば、AWS API GatewayやNginxなどで設定する際は、以下のようなヘッダーを動的に生成します。

# Nginxの設定例：管理人室のルールブック
location /api/ {
    # 誰からのアクセスを許可するか（*は全員OK、特定のドメインを指定するのが安全！）
    add_header 'Access-Control-Allow-Origin' 'https://myapp.com';
    
    # どんなメソッドを許可するか
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    
    # どんなヘッダー情報を含めていいか
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';

    # プリフライトの応答（OPTIONSメソッドが来た時の処理）
    if ($request_method = 'OPTIONS') {
        return 204; # 「了解！何も返さないけど許可するよ」という合図
    }
}

ここがポイント！

Access-Control-Allow-Origin: 「どこの住所からの手紙なら受け取るか」を指定します。
204 No Content: プリフライトに対しては、データの中身ではなく「OK」という返事だけで十分なので、このステータスコードを返します。

—

4. なぜ「動的な生成」が必要なの？

さて、ここで少し深い話を。なぜ静的に固定せず「動的」にする必要があるのでしょうか。

例えば、開発環境（dev.myapp.com）と本番環境（myapp.com）でAPIを使い回したい場合、Access-Control-Allow-Originを固定してしまうと片方でエラーになりますよね。

APIゲートウェイでリクエストヘッダーの Origin を読み取り、「あ、君は許可リストに載っているから、Access-Control-Allow-Origin: 君のドメイン で返してあげるよ」と動的に書き換えることで、柔軟かつ安全な通信が実現できるのです。

—

最後に：ネットワークを愛する皆さんへ

CORSエラーが出たとき、初心者の多くは「とりあえず Access-Control-Allow-Origin: * にしちゃえ！」と設定しがちです。でも、これはマンションのオートロックを誰でも入れるようにするのと同じこと。

インフラエンジニアとして、「どのオリジンなら安全か？」をしっかり見極め、最小限の権限を与えること。これこそが、美しいネットワーク設計の第一歩です。

パケットが届く裏側には、こうした一つひとつの「礼儀」がある。そう思うと、Webの通信も少し愛おしく感じませんか？

また次回の記事で、より深いプロトコルの世界でお会いしましょう。質問があればコメント欄でいつでもどうぞ！