CORSエラーが消えない人へ：メッセージ別の直し方とClaude Codeでの安全な設定

フロントを localhost:3000、APIを localhost:8787 で立ち上げただけ。コードはどこも間違っていない。なのにブラウザの赤いコンソールには blocked by CORS policy。

僕も最初、これを「APIが壊れてる」と勘違いして、サーバー側のコードを1時間いじり倒しました。要するに、コードは正しかった。足りなかったのは「ブラウザに読んでいいよと伝えるヘッダー」一行だけ。CORSエラーは、原因がAPIの中ではなくブラウザとAPIの“約束”の部分にあるから、最初は本当にどこを直せばいいのか分かりません。

この記事は、その約束の直し方を「エラーメッセージ別」にまとめたものです。CORSは初心者が必ず一度は踏みます。だから、まず自分のコンソールに出ているメッセージを見つけて、対応する節に飛んでください。

この記事の要点

• CORSは「認証」でも「攻撃防御」でもない。ブラウザがレスポンスを読めるかどうかを、サーバーがヘッダーで許可する仕組み。
• まず直すべきは、コンソールに出ているエラーメッセージそのもの。文言ごとに原因と一手が決まっている（後述の早見表）。
• 一番やりがちな事故が Access-Control-Allow-Origin: * と credentials: true の併用。これはブラウザ仕様で禁止されていて、絶対に通らない。
• preflight（OPTIONSの事前確認）が認証で弾かれると、本リクエストは1回も飛ばない。
• 検証はブラウザで悩む前に curl で。preflightと本リクエストを分けて投げると原因が即わかる。

そもそもCORSは何を守っているのか

CORS（Cross-Origin Resource Sharing）は、違うオリジン同士のブラウザ通信を、サーバー側が許可するための仕組みです。

オリジンは「スキーム＋ホスト＋ポート」の組み合わせ。https://app.example.com と https://api.example.com は別オリジンだし、http://localhost:3000 と http://localhost:5173 も、ポートが違うだけで別オリジンです。この「ポート違いも別物」を忘れると、開発中にハマります。

ここで一番大事な勘違いを先に潰しておきます。CORSは認可（権限チェック）ではありません。curl やサーバー間の通信はCORSの影響をまったく受けず、素通りします。止まるのはブラウザの中のJavaScriptだけ。だから「CORSで管理画面を守れる」と思っていると、curl で叩かれた瞬間に防御がゼロだったと気づきます。認証・CSRF対策・レート制限・セキュリティヘッダーは、CORSとは完全に別物として設計してください。

流れを図にするとこうです。ブラウザはいきなり本番のリクエストを送らず、先に OPTIONS で「この通信、許可されてますか?」と聞きにいきます。

sequenceDiagram
  participant Browser as Browser
  participant API as API server
  Browser->>API: OPTIONS /api/messages<br/>Origin + Access-Control-Request-*
  API-->>Browser: 204 + Access-Control-Allow-*
  Browser->>API: POST /api/messages<br/>Cookie or Authorization
  API-->>Browser: 200 + Access-Control-Allow-Origin

この事前確認が preflight（プリフライト） です。ブラウザはJSONの POST、Authorization ヘッダー付き、PUT や DELETE などを送る前に、必ずこの OPTIONS を飛ばします。APIが Access-Control-Allow-Methods や Access-Control-Allow-Headers をきちんと返さないと、本リクエストはそもそも送られません。「POSTが届いてない」とサーバーログを見ても何もない理由は、たいていこれです。

エラーメッセージ別・直し方の早見表

まずはこの表で、自分のコンソールに出ている文言を探してください。CORSエラーは怖く見えますが、文言ごとに原因と直し方はほぼ決まっています。

ブラウザのエラー文（一部）	起きていること	直す場所
No 'Access-Control-Allow-Origin' header is present	APIがそのoriginを許可するヘッダーを返していない	allowlistにoriginを追加して反射させる
The value of the 'Access-Control-Allow-Origin' header ... must not be the wildcard '*' when credentials mode is 'include'	* と credentials を併用している	* をやめ、リクエストのoriginを反射する
Method POST is not allowed by Access-Control-Allow-Methods	許可メソッドにPOSTが入っていない	Access-Control-Allow-Methods にメソッド追加
Request header field authorization is not allowed by Access-Control-Allow-Headers	preflightで要求したヘッダーが許可リストにない	Access-Control-Allow-Headers にそのヘッダー追加
Response to preflight request doesn't pass access control check（401/403を伴う）	OPTIONS が認証で弾かれている	preflightを認証の前に通す
... has been blocked by CORS policy（他に手がかりなし）	多くはエラーレスポンスにCORSヘッダーが無い	4xx/5xxにも同じCORSヘッダーを付ける

下にそれぞれの「なぜ」と直し方を、よく出る順に書きます。

1. 「Access-Control-Allow-Origin がない」

一番多いやつです。原因はだいたい2つ。そのoriginを許可していないか、エラー時にヘッダーを付け忘れているか。

前者はallowlist（許可リスト）にドメインを足すだけ。ここでありがちなのが、https://app.example.com/ と末尾スラッシュ付きで登録してしまうミス。originにパスやスラッシュは含まれないので、これだと永遠に一致しません。登録するのは https://app.example.com だけです。

2. 「* は credentials mode が include のとき使えない」

CookieやAuthorizationを送る設定（credentials: "include"）にしているのに、サーバーが Access-Control-Allow-Origin: * を返している状態。これはブラウザ仕様で明確に禁止されていて、設定を直さない限り100%通りません。MDNにもはっきり書かれています。

直し方は「* をやめて、リクエストのoriginをそのまま反射する」。ただし反射する前に、必ずallowlistで照合してから返してください。何も見ずに反射すると、どんなサイトからでも認証付きで読めてしまいます。

3. 「Method / header が allowed じゃない」

preflightでブラウザは「POSTを使いたい」「Authorizationヘッダーを付けたい」と申告します。サーバーの Access-Control-Allow-Methods / Access-Control-Allow-Headers にそれが入っていないと、ここで止まります。実際に使うメソッドとヘッダーを、preflightの要求と一致させてください。多すぎても少なすぎてもダメです。

4. preflightが401/403になる（一番ハマる）

OPTIONS リクエストには、ブラウザはCookieもAuthorizationも付けません。なのに認証middlewareが OPTIONS を「トークンが無い」と弾いて401/403を返すと、preflightが失敗し、本リクエストは1回も飛びません。preflightは認証の前に処理する——これが鉄則です。フレームワークによってはミドルウェアやプラグインの登録順がそのまま事故になります。

5. 「とにかくCORSでblockされた」だけ出る

手がかりが少ないこのパターン、犯人はたいていエラーレスポンスにCORSヘッダーが無いことです。正常時のレスポンスにはヘッダーを付けたのに、4xx/5xxには付け忘れている。すると、実体は認証エラーやバリデーションエラーなのに、ブラウザにはCORSエラーとしてしか見えず、調査が迷走します。4xx/5xxにも同じCORSヘッダーを付けるだけで、本当の原因が見えるようになります。

まず決める4項目

コードを書く前に、この4つを決めてください。ここを曖昧にしたままClaude Codeへ「CORS設定して」と丸投げすると、* で全許可するコードや、開発用のlocalhostが本番に残るコードが平気で出てきます。

決める項目	例	注意点
許可するorigin	https://app.example.com、https://admin.example.com	パスは含めない。末尾スラッシュも不要
認証情報を送るか	Cookie、Authorization header	Cookieを使うなら credentials と SameSite=None; Secure も確認
許可するメソッド	GET,POST,PUT,PATCH,DELETE,OPTIONS	実際に使うものだけにする
許可するヘッダー	Content-Type,Authorization,X-Request-ID	preflightで要求されるヘッダーと一致させる

この4項目が決まっていれば、あとはフレームワークに当てはめるだけです。

ExpressでのCORS設定

Node.js 20以上を想定した最小構成です。cors middlewareは origin に関数を渡すと、リクエストごとに許可判定できます。認証付きを扱うので、allowlistに一致したoriginだけを反射して、credentials: true を付けます。

npm init -y
npm install express cors
node server.mjs

// server.mjs
import express from "express";
import cors from "cors";

const app = express();

// 許可するoriginを完全一致で持つ（パス・末尾スラッシュは入れない）
const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com",
  "http://localhost:3000",
  "http://localhost:5173",
]);

function isAllowedOrigin(origin) {
  // Originヘッダーが無い = ブラウザ以外（curlやサーバー間）。CORS対象外なので通す
  if (!origin) return true;
  if (allowedOrigins.has(origin)) return true;
  // 開発時だけ任意のlocalhostポートを許可（本番では効かせない）
  return process.env.NODE_ENV !== "production" && /^http:\/\/localhost:\d+$/.test(origin);
}

const corsOptions = {
  origin(origin, callback) {
    callback(null, isAllowedOrigin(origin));
  },
  credentials: true, // Cookie/Authorizationを使うなら必須。ただし * とは併用不可
  methods: ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"],
  allowedHeaders: ["Content-Type", "Authorization", "X-Request-ID"],
  exposedHeaders: ["X-Request-ID"],
  maxAge: 86400, // preflight結果を1日キャッシュし、毎回OPTIONSが飛ぶのを防ぐ
  optionsSuccessStatus: 204,
};

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (origin && !isAllowedOrigin(origin)) {
    return res.status(403).json({ error: "Origin not allowed" });
  }
  next();
});

app.use(cors(corsOptions));
app.use(express.json());

app.get("/api/health", (_req, res) => {
  res.setHeader("X-Request-ID", crypto.randomUUID());
  res.json({ ok: true });
});

app.post("/api/messages", (req, res) => {
  res.setHeader("X-Request-ID", crypto.randomUUID());
  res.json({ ok: true, received: req.body });
});

app.listen(8787, () => {
  console.log("API listening on http://localhost:8787");
});

開発時だけ任意のlocalhostポートを許可しています。本番では NODE_ENV=production を立てて、allowedOrigins に明示したドメインだけを通してください。Origin ヘッダーが無いサーバー間通信はCORS対象外なので許していますが、APIキーやJWTの認証チェックは別途必要です。ここを忘れると「CORSは厳しくしたのに認証はガラ空き」になります。

FastifyでのCORS設定

Fastifyは @fastify/cors を使います。origin は真偽値・文字列・配列・関数で指定できますが、正規表現や関数で雑に許可するとDoSや想定外許可の温床になるので、まずはSetで完全一致させるのが堅実です。

npm init -y
npm install fastify @fastify/cors
node server.mjs

// server.mjs
import Fastify from "fastify";
import cors from "@fastify/cors";

const app = Fastify({ logger: true });

const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com",
  "http://localhost:3000",
  "http://localhost:5173",
]);

function isAllowedOrigin(origin) {
  if (!origin) return true;
  if (allowedOrigins.has(origin)) return true;
  return process.env.NODE_ENV !== "production" && /^http:\/\/localhost:\d+$/.test(origin);
}

app.addHook("onRequest", async (request, reply) => {
  const origin = request.headers.origin;
  if (origin && !isAllowedOrigin(origin)) {
    return reply.code(403).send({ error: "Origin not allowed" });
  }
});

await app.register(cors, {
  origin(origin, callback) {
    callback(null, isAllowedOrigin(origin));
  },
  credentials: true,
  methods: ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"],
  allowedHeaders: ["Content-Type", "Authorization", "X-Request-ID"],
  exposedHeaders: ["X-Request-ID"],
  maxAge: 86400,
  strictPreflight: true,
});

app.get("/api/health", async () => ({ ok: true }));

app.post("/api/messages", async (request) => {
  return { ok: true, received: request.body };
});

await app.listen({ port: 8787, host: "0.0.0.0" });

Fastifyはプラグインの登録順が命です。認証プラグインや独自hookが OPTIONS を403にしてしまうと、さっきの「preflightが弾かれる」事故そのものになります。Claude Codeに直してもらうときは、CORS plugin・認証hook・ルーティングの登録順まで見せると精度が上がります。

Cloudflare WorkersでのCORS設定

WorkersはFetch APIの Request / Response を直接扱います。OPTIONS を自分で返し、許可したoriginにだけ Access-Control-Allow-Origin を返します。エッジでoriginごとにレスポンスが変わる場合は、Vary: Origin を忘れないこと。これが無いと、別origin向けのヘッダーがCDNにキャッシュされて混線します。

// src/index.ts
const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com",
  "http://localhost:3000",
]);

function getCorsHeaders(request: Request): HeadersInit | null {
  const origin = request.headers.get("Origin");
  if (!origin) return {};
  if (!allowedOrigins.has(origin)) return null; // 許可外は null を返して呼び出し側で403に

  return {
    "Access-Control-Allow-Origin": origin,
    "Access-Control-Allow-Credentials": "true",
    "Access-Control-Allow-Methods": "GET,POST,OPTIONS",
    "Access-Control-Allow-Headers": "Content-Type,Authorization,X-Request-ID",
    "Access-Control-Max-Age": "86400",
    "Vary": "Origin", // origin別レスポンスがキャッシュで混ざるのを防ぐ
  };
}

export default {
  async fetch(request: Request): Promise<Response> {
    const corsHeaders = getCorsHeaders(request);
    if (corsHeaders === null) {
      return Response.json({ error: "Origin not allowed" }, { status: 403 });
    }

    // preflightはここで完結させる
    if (request.method === "OPTIONS") {
      return new Response(null, { status: 204, headers: corsHeaders });
    }

    const url = new URL(request.url);
    if (url.pathname === "/api/messages" && request.method === "POST") {
      const body = await request.json().catch(() => ({}));
      return Response.json({ ok: true, received: body }, { headers: corsHeaders });
    }

    // 404にもCORSヘッダーを付ける。付けないと原因がブラウザから見えない
    return Response.json({ error: "Not found" }, { status: 404, headers: corsHeaders });
  },
};

Workersでよくある失敗が、通常レスポンスにだけCORSヘッダーを付けて、OPTIONS やエラーレスポンスに付け忘れること。ブラウザのコンソールにはCORSエラーしか見えず、実体は認証エラーやバリデーションエラーだった、という調査が長引きます。上のコードは404にもヘッダーを付けているのがポイントです。

Next.js Route HandlerでのCORS設定

Next.jsのApp Routerでは、APIごとの route.ts でWeb標準の Request / Response を使えます。公式ドキュメントにもCORSヘッダーを付ける例がありますが、認証付きAPIでは * ではなくallowlistを使います。

// app/api/messages/route.ts
const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com",
  "http://localhost:3000",
]);

function getCorsHeaders(request: Request): HeadersInit | null {
  const origin = request.headers.get("Origin");
  if (!origin) return {};
  if (!allowedOrigins.has(origin)) return null;

  return {
    "Access-Control-Allow-Origin": origin,
    "Access-Control-Allow-Credentials": "true",
    "Access-Control-Allow-Methods": "POST,OPTIONS",
    "Access-Control-Allow-Headers": "Content-Type,Authorization,X-Request-ID",
    "Access-Control-Max-Age": "86400",
    "Vary": "Origin",
  };
}

// OPTIONS（preflight）を明示的に実装する
export async function OPTIONS(request: Request) {
  const headers = getCorsHeaders(request);
  if (headers === null) {
    return Response.json({ error: "Origin not allowed" }, { status: 403 });
  }
  return new Response(null, { status: 204, headers });
}

export async function POST(request: Request) {
  const headers = getCorsHeaders(request);
  if (headers === null) {
    return Response.json({ error: "Origin not allowed" }, { status: 403 });
  }

  const body = await request.json().catch(() => ({}));
  return Response.json({ ok: true, received: body }, { headers });
}

next.config.js の headers() で一括付与する手もありますが、originごとに出し分ける認証APIではRoute Handler内で判定したほうがレビューしやすいです。静的な公開APIだけなら headers() で十分です。

ブラウザで悩む前にcurlで切り分ける

CORSは、ブラウザのコンソールを睨んでいても原因が見えにくい。僕は今は、まず curl でpreflightと本リクエストを別々に投げます。見るのは Access-Control-Allow-Origin がリクエストの Origin と完全一致しているか、Access-Control-Allow-Credentials: true が返っているか、の2点です。

# 1) preflight（OPTIONS）だけを確認
curl -i -X OPTIONS http://localhost:8787/api/messages \
  -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: Content-Type, Authorization"

# 2) 本リクエスト（POST）を確認
curl -i -X POST http://localhost:8787/api/messages \
  -H "Origin: http://localhost:3000" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer dev-token" \
  --data '{"text":"hello"}'

# 3) 許可外originがちゃんと403で弾かれるかも確認
curl -i -X OPTIONS http://localhost:8787/api/messages \
  -H "Origin: https://evil.example" \
  -H "Access-Control-Request-Method: POST"

curl でヘッダーが正しく返るのにブラウザだけ失敗するなら、犯人は credentials 周りか * の併用です。ブラウザ側はこう確認します。Cookieを送るなら credentials: "include" が要りますが、サーバーが Access-Control-Allow-Origin: * を返しているとブラウザはレスポンスを読ませてくれません。

await fetch("http://localhost:8787/api/messages", {
  method: "POST",
  credentials: "include", // Cookieを送るならこれが必須
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer dev-token",
  },
  body: JSON.stringify({ text: "hello" }),
});

具体的な落とし穴まとめ

ここまでに出てきたものも含め、踏みやすい順に並べておきます。詰まったらまずこの表を上から確認してください。

落とし穴	何が起きるか	修正
* と credentials: true を併用する	ブラウザがレスポンスをブロックする	明示的なoriginを反射する
https://app.example.com/ を登録する	末尾スラッシュ付きで一致せず失敗	originは https://app.example.com だけ
localhost だけを許可する	ポート違いで失敗	http://localhost:3000 のようにポートまで書く
OPTIONS を認証必須にする	preflightが401/403で止まる	preflightは認証前に処理する
エラーレスポンスにCORSヘッダーがない	本当の原因がブラウザに見えない	4xx/5xxにも同じCORSヘッダーを付ける
CDNでorigin別レスポンスをキャッシュ	別origin向けヘッダーが混ざる	Vary: Origin を付ける
CORSを認可だと思う	curlやサーバー間通信は止まらない	認証・認可・CSRF対策を別に実装する

こんな場面で実際に使う

SPAとAPIを別ドメインで運用する。 Reactを https://app.example.com、APIを https://api.example.com に置き、ログインCookieを使うなら、credentials: true・Cookieの SameSite=None; Secure・CSRF対策をセットで確認します。CORSだけ直しても、この3点が揃わないとログインが通りません。

管理画面だけ追加で許可する。 https://admin.example.com をallowlistに足し、一般アプリとは別の権限チェックをAPI側で行います。繰り返しますが、CORSで管理者を守れるわけではありません。CORSは「読めるorigin」を絞るだけで、管理者権限は別の認可ロジックの仕事です。

WorkersをBFF（Backend for Frontend）や軽いプロキシにする。 外部APIをブラウザから直接呼べないとき、Workerで受けてサーバー側で外部へ接続します。このときブラウザに返すWorkerのレスポンスにCORSヘッダーを付けます。

公開読み取りAPI。 認証情報を送らず、誰に読まれてもいいデータだけなら Access-Control-Allow-Origin: * も選択肢です。ただし将来CookieやAuthorizationを足す予定があるなら、最初からallowlistで設計したほうが移行がラクです。

Claude Codeへのレビュー依頼テンプレ

ここからはClaude Code向け。CORSは人間の目視レビューだと「* とcredentialsの併用」「本番に残ったlocalhost」を見落としがちなので、僕はテンプレに観点を固定して貼っています。コードだけでなく、ブラウザのエラー全文・curl結果・デプロイ先ドメインを一緒に渡すのがコツです。

このリポジトリのCORS設定をレビューしてください。
確認観点:
- credentials付きリクエストでAccess-Control-Allow-Origin: *を使っていないか
- allowlistがscheme/host/portの完全一致になっているか
- OPTIONS preflightが認証middlewareより前に処理されるか
- 4xx/5xxレスポンスにも必要なCORSヘッダーが付くか
- CDNやWorker経由の場合にVary: Originが必要か
修正が必要なら最小差分で提案してください。

次のCORSエラーを原因別に切り分けてください。
ブラウザエラー:
<ここにDevTools Consoleの全文>

curl preflight:
<curl -i -X OPTIONS ... の結果>

期待するorigin:
https://app.example.com

API側の該当ファイルを読んで、再現手順、原因、修正案、追加テストを出してください。

エラー全文とcurl結果を一緒に渡すと、Claude Codeが「これはCORSではなく認証エラーです」と切り分けてくれることもあります。表面のCORSエラーに引っ張られず、実体を見てもらえるのが大きいです。

よくある質問

Q. Access-Control-Allow-Origin: * を付ければ全部解決しませんか? 認証情報（Cookie/Authorization）を送らない公開APIなら、それで解決します。でもCookieやトークンを送る場合、* は仕様で禁止されていて必ずブロックされます。認証付きならallowlistでoriginを反射してください。

Q. preflightの OPTIONS が何度も飛んで遅いです。 Access-Control-Max-Age（例では86400秒）を設定すると、ブラウザがpreflight結果をキャッシュし、その間は OPTIONS を再送しません。値はブラウザ側に上限があるので、長くしすぎても頭打ちになります。

Q. CORSを設定すればAPIのセキュリティは大丈夫? いいえ。CORSはブラウザ内のJavaScriptしか止めません。curl やサーバー間通信は素通りします。認証・認可・CSRF対策・レート制限・セキュリティヘッダーは、CORSとは別に実装してください。

Q. 開発のlocalhostはどうするのが安全? 開発時だけ NODE_ENV !== "production" の条件で任意のlocalhostポートを許可し、本番ではこの分岐を効かせないのが安全です。許可リストにlocalhostを直書きして本番にそのまま残すのが、典型的な事故です。

Q. Vary: Origin はいつ必要? CDNやエッジ（Cloudflareなど）でoriginごとにレスポンスが変わる場合に必要です。これが無いと、あるorigin向けに返したヘッダーが別originのリクエストにもキャッシュから返り、CORSエラーの原因になります。

関連記事と公式ドキュメント

仕様の確認はMDNのCORSガイドが基準。Expressならcors middleware、Fastifyなら@fastify/cors、WorkersならCloudflareのCORS例、Next.jsならRoute Handlersを見てください。

CORSだけを孤立した設定にしないために、Claude CodeでAPI開発、Webセキュリティヘッダー設定、Cloudflare Workers活用、コードレビュー手順、Claude Codeセキュリティベストプラクティスもあわせてどうぞ。Cookie・CSRF・認可・セキュリティヘッダーまで一度に点検できます。

実際に試した結果

手元でExpress版とFastify版を localhost:8787 で起動し、Origin: http://localhost:3000 のpreflightとPOSTが成功すること、https://evil.example がちゃんと403になることを確認しました。一番見落としやすかったのは、やっぱりエラーレスポンスとWorkerの OPTIONS にCORSヘッダーを付け忘れる点。ここを直すまで、認証エラーがずっとCORSエラーの顔をして僕を惑わせていました。

最後はClaude Codeに上のレビューテンプレを渡し、「* とcredentialsの併用がないか」「Vary: Origin が要る箇所はどこか」「localhostが本番に残っていないか」を再確認させる。この流れが、今のところ一番事故りません。CORSは仕組みさえ腹落ちすれば、怖いエラーではなくなります。詰まったら、まずコンソールの一行を早見表で引いてみてください。

実装テンプレートやレビュー資料をチームに展開したい方は、教材一覧ものぞいてみてください。