この記事は脆弱エンジニアの Advent Calendar 2025 4日目の記事です！

はじめに

Webフロントエンドを触っていて、いざAPIにアクセスするぞと思ったとき、こういうエラーが出たことって、ありますよね。

Access to fetch at ****** from origin ****** has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

なんか調べるとサーバー (API) 側でこういうヘッダを設定してあげると直るらしいですね。

Access-Control-Allow-Origin: *

これ自体は間違いではないのですが、これだと CORS が邪魔者みたいですよね。でも実は CORS は Web の世界においてセキュリティを維持する重要な役割を担っているのです。

この記事では

誰が
なぜ
どのように

CORS の制限を課しているのかについてより詳しく掘り下げていこうと思います。

この記事では気持ちの理解に重点を置いて説明しているため、各用語の説明や細かい挙動の説明などは意図的に省略しています。詳細についてはMDNなどのドキュメントを用いて補完してください。

オリジン間リソース共有 (CORS) | MDN
同一オリジンポリシー | MDN

CORS #とは

CORS とはブラウザに実装されたセキュリティ機構です。JavaScriptから送られたAPIリクエストをブラウザがブロックしてエラーにしています。

逆に言えばサーバーサイドからリクエストを送ったり、curl やら Postman やらを使ってリクエストを送るときには CORS は関係ありません。

そして CORS の役割は 「異なるオリジン間でのリソースの共有を適切に行えるようにすること」 です。これだけだと分からないと思うので、もう少し掘り下げていきましょう。

この説明は CORS と SOP をやや混同していますが、次の章以降で詳しく説明していきます。

CORS は何をするのか

CORS の役割はリソースの共有を適切に行えるようにすることでした。逆に不適切なリソースの共有というのはどういう状況を指すのでしょうか？具体例を見ていきましょう。

https://bank.example で銀行アプリが動いていて、https://bank.example/balance をAPIで叩くと残高が取得できるとします。攻撃者が残高APIにアクセスする https://attacker.example というサイトを用意して、銀行アプリの利用者がそのサイトにアクセスしたらどうなるでしょうか？

勝手に残高を盗み見られるのは困るので、これは不適切なリソースの共有と言えます。ここでのリソースは https://bank.example/balance にアクセスして得られるレスポンス、すなわち残高情報のことを指します。

幸運なことに、現代のWebブラウザであればこのような不適切なアクセスは通常ブロックされます。このアクセスをブロックする仕組みを SOP (Same-Origin Policy) と呼びます。ユーザーがアクセスしたサイト (https://attacker.example) とJavaScriptによってアクセスしようとしているサイト (https://bank.example/balance) のオリジンが異なるため、SOP に従ってリクエストをブロックします。

ここで https://myapp.example にアプリのフロントエンドを立てて、そこから https://api.myapp.example のAPIサーバーにアクセスするようなケースを考えてみます。アプリのプロフィールページなどに表示するために https://api.myapp.example/me からログインしているユーザーの情報を取得しようとします。

これは適切なリソースの共有に見えます。なのでリクエストは通って欲しいのですが、先と同じ理屈で SOP によって弾かれてしまいます。

これは困りました。これを上手く回避する方法が CORS です。¹

CORS ではリソースを持っている/返す側²がどのオリジンからアクセスされて良いかを制御します。この制御には CORS ヘッダと呼ばれるヘッダを用います。例えば冒頭で出てきた Access-Control-Allow-Origin: * というのは全てのオリジンからのアクセスを許可するという意味です。

myapp の例で言えば、https://api.myapp.example からのレスポンスに Access-Control-Allow-Origin: https://myapp.example というヘッダを付ければ良いことが分かります。

なぜ SOP / CORS が必要なのか

ブラウザは変なWebサイトを開いても「安全」である必要性があります。この「安全」というのは様々な側面があるのですが、その1つとしてサイト間での干渉を防ぐというものがあります。

現代は様々なことがWeb上で行われるようになりましたが、これはサイト間で適切にリソース³が分離されていることによって安全性が担保されています。逆にサイト間で干渉が起きてしまうと、例えば攻撃者のサイトにアクセスすると、そこから銀行アプリにアクセスされて残高を盗み見られてしまう、といった攻撃が成立してしまいます。これを防ぐために SOP が存在しています。

SOP はブラウザのデフォルトの挙動です。ブラウザは安全を保つためにデフォルトではリクエストを厳しく弾きます。しかし myapp / api.myapp の例のように、開発者の意図したアクセスに限り許可するために CORS を使います。

このように SOP / CORS はブラウザの非常に基本的な安全性を担保するために欠かせない機能なのです。

しかしこれは信頼できないJavaScriptを実行するというブラウザの都合でしかないので、ブラウザ以外の環境 (curlなど) で開発者の意図したリクエストしか送らない場合には全く必要ありません。⁴

まとめ

開発をしていて CORS に阻まれてしまうと「ムッ」となるかもしれませんが、ブラウザの安全性を保つための重要な仕組みによって仕方なくこうなっているのです。今度から CORS エラーを見かけたら「今日もWebを安全にしていて偉いねﾖｼﾖｼヾ(・ω・｀)」という気持ちで見てあげてください。

この記事では意図的に CORS の詳しい設定の仕方などについては触れていませんでしたが、その辺りについては MDN や他のブログなどを参考にしていただけると幸いです。

ちなみに、このような単純なケースであれば https://myapp.example/api 以下を https://api.myapp.example にプロキシするといった方法でオリジンを同じにすることで回避することができます。 ↩
この概念に名前はついているんでしょうか？ ↩
ここでのリソースは localStorage、Cookie、ブラウザの権限など様々な概念をゆるりとまとめたものとして定義しておきます。 ↩
というかまず現在のオリジンという概念が基本的にないので SOP を定義できません。 ↩