0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

CORSエラーとは?ブラウザとサーバーの役割について

Posted at

はじめに

Web開発をしていると、ある日突然コンソールに赤字で表示される「CORSエラー」。
このエラーに遭遇すると、多くの開発者が頭を抱えることでしょう。
「なんだかよくわからないけど、サーバー側で設定を追加したら直った」という経験はありませんか?

本記事では、CORSエラーの正体、発生する理由、そして解決方法について、わかりやすく解説します。

CORSとは何か?登場人物で理解する

CORSを理解するために、関係者を登場人物に例えてみましょう。

  • ブラウザくん: ユーザーの代理人。Webサイトを表示したり、データを取得したりする働き者
  • フロントエンドさん: ブラウザくんの中で動いているWebアプリ。外部のサーバーからデータを取得したい
  • APIサーバーさん: データや機能を提供するサーバー。フロントエンドさんのリクエストに応える
  • オリジン警備員: ブラウザくんの中にいるセキュリティ担当。怪しい通信がないか見張っている

オリジンとは?

オリジンとは、Webサイトやサーバーの「住所」のようなものです。

  • プロトコル (例: https://)
  • ドメイン (例: example.com)
  • ポート番号 (例: :443 - デフォルトは省略されることが多い)

この3つの組み合わせがオリジンです。一つでも違えば「別のオリジン」とみなされます。

CORSエラーが発生する仕組み

なぜCORSエラーは起きるのか?

  1. フロントエンドさんのお願い:
    フロントエンドさん (例: https://app.example.com) が、APIサーバーさん (例: https://api.example.com) にデータをリクエストします

  2. オリジン警備員のチェック:
    ブラウザくんの中のオリジン警備員が「このリクエストは違うオリジン宛だな。安全か確認しないと!」とチェックします

  3. 許可証の確認:
    オリジン警備員は、APIサーバーさんからの応答に「許可証 (CORSヘッダー)」が付いているか確認します

  4. ブロック! (CORSエラー):
    もし許可証がなければ、オリジン警備員は「通せん!」と、データの受け取りをブロックします。これがCORSエラーです

誰がブロックしているのか?

アクセスをブロックしているのは「ブラウザ内のオリジン警備員」です。

「サーバー側が許可していないなら、サーバーがエラーを返せばそれで済むのでは?」と思うかもしれません。しかし、実際にブロックしているのはブラウザなのです。

なぜブラウザがブロックする必要があるのか?

  • ユーザーを守るため:
    悪意のあるWebサイトが、ユーザーがログイン中の別のサービスのAPIを勝手に呼び出すのを防ぎます

  • サーバーは普通に応答する:
    サーバー自体は、どのオリジンからのリクエストにも普通に応答します。curlなどで直接リクエストすれば、CORSエラーは起きません

  • ブラウザの役割:
    ブラウザは、CORSヘッダーをチェックし、「許可がない」と判断したら、応答データをJavaScriptに渡さないようにブロックします

CORSエラーの解決方法

CORSエラーを解決するには、APIサーバー側に「このオリジンからのリクエストは許可します」という許可証 (CORSヘッダー) を発行してもらう必要があります。

サーバー側の設定方法

  • Access-Control-Allow-Originヘッダーを設定する:
    これが最も重要です。ここに許可するフロントエンドのオリジンを指定します。

    Access-Control-Allow-Origin: https://app.example.com
    

    安易に * (ワイルドカード) を指定すると、どのサイトからでもアクセスできてしまい、セキュリティリスクが高まります。信頼できるオリジンだけを指定しましょう。

  • 必要に応じて他のヘッダーも設定する:

    • Access-Control-Allow-Methods: 許可するHTTPメソッド
    • Access-Control-Allow-Headers: 許可するリクエストヘッダー
    • Access-Control-Allow-Credentials: 認証情報を伴うリクエストを許可する場合に設定

よくある疑問と回答

疑問1: 悪意のあるサーバーが許可証をばら撒いたら危険では?

「もし悪いサーバーが『誰でもアクセスOK!』という許可証を出していたら危険では?」

  • CORSの役割: CORSは「サーバーのデータを誰に渡すか」を決めるものです。サーバーが「誰にでもデータを渡す」と決めた場合、CORSはその決定を尊重します
  • アクセスの判断: 悪意のあるサーバーにアクセスするかどうかは、最終的にはWebアプリの開発者やユーザーが判断することです

CORSは「サーバーの守衛さん」であり、「ユーザーを守る警察」ではないのです。

疑問2: サーバーがエラー時に何も返さなければ、ブラウザのブロックは不要?

「サーバー側でエラーを返すときに、重要な情報を含めなければ、ブラウザがブロックしなくても問題ないのでは?」

  • サーバー側の努力: サーバーは、エラー発生時に詳細な内部情報を含めるべきではありません。これは基本的なセキュリティ対策です
  • CORSブロックの役割: たとえサーバーが安全なエラー応答を返しても、ブラウザのCORSブロックは「Webページ上のJavaScriptによる意図しない情報利用」を防ぐための追加の防御策として重要です

結論: サーバー側で「余計な情報を返さない」努力と、ブラウザ側のCORSブロックの両方が連携することで、Webはより安全になります。

まとめ

CORSエラーは、Webのセキュリティを守るための重要な仕組みです。

  • CORSエラーは、ブラウザが異なるオリジン間の通信を制限することで発生します
  • 解決するには、サーバー側で適切なCORSヘッダーを設定し、信頼できるオリジンからのアクセスを許可する必要があります
  • CORSは、Webアプリケーションとユーザーを保護するための重要なセキュリティ機能です

CORSエラーに遭遇したら、「どのオリジンからどのオリジンへアクセスしようとしているのか」「サーバー側で許可設定はされているか」を確認しましょう。この仕組みを理解すれば、もうCORSエラーは怖くありません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?