Cross Origin Resource Sharing (CORS) - 版の履歴

2024年7月5日 (金) 02:36にAdministratorによる

2024-07-05T02:36:43Z

← 古い版		2024年7月5日 (金) 02:36時点における版
14行目:		14行目:

	# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <pre><nowiki>Origin: http://www.example.com</nowiki></pre>		# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <pre><nowiki>Origin: http://www.example.com</nowiki></pre>
	#		# service.example.comのサーバーは、これら3つのレスポンスのいずれかを送信する：
			#* リクエストされたデータは、オリジンからのリクエストが許可されていることを示す応答中の<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーとともに送られる。例えば、この場合はこうなる：<pre><nowiki>Access-Control-Allow-Origin: http://www.example.com</nowiki></pre>
			#* リクエストされたデータは、<code>Access-Control-Allow-Origin</code> (ACAO)ヘッダーと共に、すべてのドメインからのリクエストが許可されることを示すワイルドカードを持つ： <pre><nowiki>Access-Control-Allow-Origin: *</nowiki></pre>
			#* サーバーがクロスオリジン・リクエストを許可しない場合のエラー・ページ。

			ワイルドカードの同一生成元ポリシーは、ページやAPIのレスポンスが、どのサイトのどのコードからもアクセスできることを意図している場合に適切です。Google Fontsのようなパブリック・ホスティング・サービスで自由に利用できるウェブ・フォントがその例です。

			ワイルドカードの同一オリジン・ポリシーは、ページが推測不可能なURLを持ち、秘密を知っている人なら誰でもアクセスできることを意味する、オブジェクト・キャパビリティ・モデルでも広く適切に使用されている。

			つまり、HTTP認証、クライアント側SSL証明書、クッキーをクロスドメインリクエストで送ることを許可しない。

			CORSアーキテクチャでは、Access-Control-Allow-Originヘッダーは、元のWebアプリケーションサーバー（www.example.com）ではなく、外部のWebサービス（service.example.com）によって設定されることに注意してください。ここで、service.example.comはCORSを使用して、ブラウザがwww.example.com、service.example.comへのリクエストを許可する。

			サイトがヘッダ "Access-Control-Allow-Credentials:true "を指定すると、サードパーティのサイトが特権的なアクションを実行し、機密情報を取得できる可能性があります。

2024年7月5日 (金) 02:32にAdministratorによる

2024-07-05T02:32:36Z

← 古い版		2024年7月5日 (金) 02:32時点における版
13行目:		13行目:
	ユーザーがhttp://www.example.com、ページがhttp://service.example.com からデータをフェッチするためにクロスオリジン・リクエストを試みたとする。CORS対応ブラウザは、以下のようにservice.example.comへのクロスオリジン・リクエストを試みる。		ユーザーがhttp://www.example.com、ページがhttp://service.example.com からデータをフェッチするためにクロスオリジン・リクエストを試みたとする。CORS対応ブラウザは、以下のようにservice.example.comへのクロスオリジン・リクエストを試みる。

	# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <br />		# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <pre><nowiki>Origin: http://www.example.com</nowiki></pre>
	#		#

Administrator: ページの作成:「クロスオリジン・リソース・シェアリング（CORS）は、ウェブページを提供したドメインのサーバーとは異なるドメインのサー…」

2024-07-05T02:32:09Z

ページの作成:「クロスオリジン・リソース・シェアリング（CORS）は、ウェブページを提供したドメインのサーバーとは異なるドメインのサー…」

新規ページ

クロスオリジン・リソース・シェアリング（CORS）は、ウェブページを提供したドメインのサーバーとは異なるドメインのサーバー上のリソースに安全にアクセスできるようにする仕組みです。

ウェブページは、クロスオリジンの画像、スタイルシート、スクリプト、iframe、動画を自由に埋め込むことができます。特定の「クロスドメイン」リクエスト、特にAjaxリクエストは、同一オリジンセキュリティポリシーによってデフォルトで禁止されています。

CORSは、ブラウザとサーバーが相互作用して、クロスオリジン・リクエストを許可しても安全かどうかを判断する方法を定義しています。これは、純粋に同一オリジンのリクエストよりも自由度と機能性を高めますが、単純にすべてのクロスオリジンリクエストを許可するよりも安全です。

CORSの仕様はWHATWGの「Fetch Living Standard」の一部として含まれている。この仕様は、CORSが現在どのようにブラウザに実装されているかを説明しています。以前の仕様はW3C勧告として発表された。

== 概要 ==
別のドメインを指す <form> タグを使ったり、セーフリストに載っていないヘッダを含んだりすることができない JavaScript からの HTTP リクエストに対して、この仕様ではブラウザがリクエストを「プリフライト」し、HTTP OPTIONS リクエストメソッドでサーバーからサポートされているメソッドを要求し、サーバーからの「承認」があれば実際の HTTP リクエストメソッドで実際のリクエストを送信することを義務付けています。サーバーはまた、"クレデンシャル"（クッキーや HTTP 認証データを含む）をリクエストと一緒に送るべきかどうかをクライアントに通知することができます。

== 簡単な例 ==
ユーザーがhttp://www.example.com、ページがhttp://service.example.com からデータをフェッチするためにクロスオリジン・リクエストを試みたとする。CORS対応ブラウザは、以下のようにservice.example.comへのクロスオリジン・リクエストを試みる。

# ブラウザは、親ページを提供したドメインを含むservice.example.comへの余分なOrigin HTTPヘッダーを持つGETリクエストを送信します： <br />
#