CORS（Cross-Origin Resource Sharing）は、あるオリジンの Web ページが別のオリジンのサーバーにリクエストできるかどうかを制御するブラウザのセキュリティ機構です。デフォルトでは、ブラウザはクロスオリジンのリクエストをブロックします。サーバーがレスポンスヘッダーを通じて明示的に許可する必要があります。
オリジン = スキーム + ホスト + ポート。これらは異なるオリジン:
https://app.example.com → https://api.example.com (ホストが異なる)
http://localhost:3000 → http://localhost:4000 (ポートが異なる)
サーバーが許可する CORS ヘッダーを送らない限り、ブラウザはクロスオリジンのリクエストをブロックする。
つまり、 上の React アプリが の API を呼ぶのはクロスオリジンであり、API が明示的に許可しない限りブラウザがブロックします。
localhost:3000localhost:4000Access-Control-Allow-Origin: https://app.example.com ← 誰が許可されるか
Access-Control-Allow-Methods: GET, POST, PUT, DELETE ← 許可されるメソッド
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true ← Cookie / 認証を許可する
サーバーはこれらのヘッダーを送ることでアクセスを制御します。ブラウザはそれらを読み取り、ページがレスポンスを見ることを許可するかどうかを判断します。
import cors from "cors";
// ❌ すべてを許可する — 便利だが、認証付き / プライベートな API には安全でない
app.use(cors());
// ✅ 特定の信頼できるオリジンに制限する
app.use(cors({
origin: ["https://app.example.com", "http://localhost:3000"], // 許可リスト
methods: ["GET", "POST", "PUT", "DELETE"],
credentials: true, // Cookie を許可 — 特定のオリジンが必須（"*" は不可）
}));
cors ミドルウェアがヘッダーを設定してくれます。本番環境では、* ではなく**origin を許可リストに制限する**べきです。また、認証情報の許可（credentials: true）はワイルドカード * と両立しないことに注意してください。
「単純でない」リクエスト（PUT/DELETE、カスタムヘッダー、JSON）の場合、ブラウザはまず
OPTIONS の「プリフライト」リクエストを送り、許可を確認する。cors ミドルウェアは
それへの応答を自動的に処理する。
CORS はサーバーではなく、ブラウザによって強制される。curl、Postman、他のサーバーといった
非ブラウザのクライアントから API を保護するものではない — それらは CORS を無視する。
他のオリジンのブラウザ JavaScript が何をできるかを制御するだけである。
CORS は Web 開発で最もよくつまずく点の 1 つです。ほぼすべてのフロントエンドから API への構成がこれに遭遇します（特に異なるポートを使うローカル開発で）。
それが存在する理由（ブラウザの同一オリジンセキュリティ）、サーバーがヘッダーを通じてどう明示的に許可するか、どう安全に構成するか（オリジンの許可リスト化、認証情報の慎重な扱い）、そしてそれが API の認可ではなくブラウザの機構であるという決定的な事実を理解することは、ブロックされたりサーバーを過度に露出させたりすることなく、フロントエンドを Node の API に正しく安全に接続するうえで不可欠です。