CORSについて過去の自分に教える #CORS

最近、CORSについて理解してきたので、昔よくわからずにコピペでCORSの設定をしていた自分に教えるつもりでCORSについて書きます。

そもそもCORSが必要なのはなぜ？

僕がbank.comという銀行サイトを運営していたとします。
悪い人がこのbank.comに攻撃を仕掛けるためにtrap.comというサイトを作り、いろんなところへリンクを貼っていたとします。
このtrap.comはアクセスすると、一見普通のサイトですが、裏で銀行サイト（bank.com）に「xxxに1万円送金して」というリクエストを送るように仕込まれています。

trap.com失敗する

実際にはうまくいきません。

trap.comが成功する

だけどごくたまに

僕が「CORS？何それ？」という理解でbank.comを運営していた、としてください。

このようにごくたまにうまくいくことがあります。
これはbank.comへのリクエストに、bank.comへのcookieが自動で付け加えられる、という性質を悪用したためです。

こうなるとbank.comからすると

というわけでCORSが出てきます。

つまり、CORSは異なるオリジンからのリクエストを制限するものです。

ここまでのまとめ

異なるオリジンからのリクエストを制限したい→CORSという仕組みがある

CORSの仕組み

上の図では「CORS？何それ？」な僕がいたのでtrap.comからbank.comへのリクエストが成功していました。
しかしちゃんと設定すると、リクエストを送ってみてもうまくいきません。多分こんなエラーが出ます

なぜでしょう？

実際は「送金して」というリクエストを送る前にブラウザがある処理をしています。

「送金して」というリクエストを送る前に・・・

ブラウザが、bank.comへのリクエストを一旦ストップする
ブラウザが、trap.comからbank.comへリクエストを送っていいか確認のリクエストを送る（この確認のリクエストを プリフライリクエスト といいます）
bank.comは、プリフライリクエストに対して、「このオリジンからならリクエスト送っていいよ」というレスポンスを返す
ブラウザが、trap.comが許可されているか確認する。許可されていなければ最初にストップしていたリクエストを送らないでエラーを出す

という処理が行われ、trap.comからの不正なリクエストをストップできます。

このままbank.com以外からのリクエスト全てをブロックしてもいいのですが、sub.bank.comというサブドメインからのリクエストは許可したい、となったらどうしたらいいでしょうか？

CORSを設定する

sub.bank.comからのリクエストを許可する場合、CORSの設定はどこで行うか、というとサーバー側（bank.com）で行います。

Goでmiddelwareとして実装するとこんな感じになると思います。

middleware.go

// bank.comで使用するmiddleware
func MyMiddleware(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
        // https://sub.bank.comからのリクエストを許可
		w.Header().Set("Access-Control-Allow-Origin", "https://sub.bank.com")
		w.Header().Set("Access-Control-Allow-Methods", "GET,POST,OPTIONS")
        // リクエストのHeaderにContent-Typeを加えることを許可
		w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
        // プリフライリクエストはOPTIONSで送信されるので、その場合はリターンする
		if r.Method == http.MethodOptions {
			w.WriteHeader(http.StatusOK)
			return
		}
		next(w, r)
	}
}

というふうに設定するとbank.comは、sub.bank.comからのリクエストを許可することができます。

コピペでCORSの設定をしていた自分に伝えたいこと

ここで昔の自分に伝えたいことがあります。

middleware.go

// おすすめしない設定
func MyMiddleware(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
        // * からのリクエストを許可
		w.Header().Set("Access-Control-Allow-Origin", "*")

        // ~~~
	}
}

これはやめよう。
Access-Controle-Allow-Originに * を設定すると確かにエラーは出ないけど、これだと「どこからでもリクエストしてOK」ということになり危ないよ！ちゃんと許可するオリジンを指定しよう！

ここまでのまとめ

異なるオリジンからのリクエストを制限したい→CORSという仕組みがある
CORSの設定を行うと、異なるオリジンからの危ないリクエストをブロックできる（？）

ブロックできません

ブロックできない？

異なるオリジンからのリクエストをストップする流れはこんな感じでした。

trap.comが、bank.comへリクエストを送信するよう処理する
ブラウザが、そのリクエストを行う前に本当にtrap.comからbank.comへリクエストを送っていいか、bank.comへ確認する（プリフライリクエスト）
bank.comが、プリフライリクエストに対して、許可するオリジンを示したレスポンスを返す
ブラウザは、bank.comからのレスポンスをもとにtrap.comが許可されていない、と判断し、trap.comからbank.comへのリクエストをやめる

これだけみると、bank.comがtrap.comを許可しなければ、trap.comはbank.comへリクエストを送ることはできないように見えますが、注意点があります。

必ずプリフライリクエストが行われるわけではない、という点です。

リクエストがある要件を満たす場合、単純リクエストとして扱われ、プリフライリクエストが行われません。
オリジン間リソース共有#単純リクエスト

その場合、次のような流れになります。

trap.comが、bank.comへリクエストAを送信するよう処理する）
ブラウザが、リクエストAが単純リクエストである、と判断しリクエストAを送信する
bank.comが、リクエストAを受け取り、レスポンスを返す
ブラウザは、bank.comからのレスポンスをもとにtrap.comが許可されていない、と判断し、bank.comからのレスポンスを表示しない

リクエスト自体は送信されてしまい、サーバーもリクエストを受け取ってしまいます。
なので「CORSの設定をしたから安心」とはなりません。

対策

対策としては単純リクエストの場合、使用できるヘッダーが限られています。
なのでsub.bank.comに単純リクエストでは使用できないカスタムヘッダーを使うようにし強制し、bank.com側ではカスタムヘッダーが付与されていない場合は拒否するように変更します。
そうすることで必ずプリフライリクエストが行われ、許可していないサイトからのリクエストをブロックできます。

middleware.go

// カスタムヘッダーに対応
func MyMiddleware(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Access-Control-Allow-Origin", "https://sub.bank.com")
		w.Header().Set("Access-Control-Allow-Methods", "GET,POST,OPTIONS")
		// カスタムヘッダーを使用するために修正
		w.Header().Set("Access-Control-Allow-Headers", "Content-Type,X-Custom-Header")
		if r.Method == http.MethodOptions {
			w.WriteHeader(http.StatusOK)
			return
		}

		// カスタムヘッダーが付与されていない場合は単純リクエストの可能性があるので拒否する
		h := r.Header.Get("X-Custom-Header")
		if h != "secret" {
			w.WriteHeader(http.StatusBadRequest)
			return
		}

		next(w, r)
	}
}

まとめ

異なるオリジンからのリクエストを制限したい→CORSという仕組みがある
CORSの設定を行うと、異なるオリジンからの危ないリクエストをブロックできる、わけではない。追加の設定が必要。

昔の自分に伝えたいこと

Access-Control-Allow-Origin: * はやめよう
CORSのチェックはブラウザで行われるからフロント側のコードいじっても解決しないよ
Same-OriginとSame-Siteは違うから気をつけて
コピペでエラー回避する前に、その設定について調べる＆自分で試すと面白いからオススメ

CORSについて過去の自分に教える

そもそもCORSが必要なのはなぜ？

trap.com失敗する

trap.comが成功する

ここまでのまとめ

CORSの仕組み

CORSを設定する

コピペでCORSの設定をしていた自分に伝えたいこと

ここまでのまとめ

ブロックできない？

対策

まとめ

昔の自分に伝えたいこと

参考