Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CORSをちゃんと理解する atmaバックエンド勉強会#4
Search
Yamaguchi Takahiro
July 07, 2021
Technology
0
370
CORSをちゃんと理解する atmaバックエンド勉強会#4
atmaバックエンド勉強会#4の資料です。
Yamaguchi Takahiro
July 07, 2021
Tweet
Share
More Decks by Yamaguchi Takahiro
See All by Yamaguchi Takahiro
コンペを気楽に開催しよーぜ!@関西Kaggler会
nyk510
0
1.1k
Django のセキュリティリリースを見る
nyk510
0
60
3分でMLアプリを作る 〜推論コードにちょっとのStreamlitを添えて〜
nyk510
1
1k
硬派で真面目なグラフを描く
nyk510
0
480
pythonで気軽にパッケージを作るのは良いという話。
nyk510
14
9.5k
RestAPIのページネーション atma バックエンド勉強会 #3
nyk510
1
860
AWS CPU Credit を完全に理解する
nyk510
0
420
atmaCup#8 Opening
nyk510
0
230
オンサイトデータコンペの魅力: 関わる全員が楽しいコンペ設計のための取り組み
nyk510
3
5.3k
Other Decks in Technology
See All in Technology
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
150
大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質
staka121
PRO
3
410
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
700
Pwned Labsのすゝめ
ken5scal
0
280
CDKのコードを書く環境を作りました with Amazon Q
nobuhitomorioka
1
150
Goで作って学ぶWebSocket
ryuichi1208
3
2.5k
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
580
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
340
短縮URLをお手軽に導入しよう
nakasho
0
140
プロダクトエンジニア 360°フィードバックを実施した話
hacomono
PRO
0
140
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
13
4.1k
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Writing Fast Ruby
sferik
628
61k
It's Worth the Effort
3n
184
28k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Bash Introduction
62gerente
611
210k
Being A Developer After 40
akosma
89
590k
4 Signs Your Business is Dying
shpigford
182
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
GitHub's CSS Performance
jonrohan
1030
460k
Building Your Own Lightsaber
phodgson
104
6.2k
Transcript
CORSをちゃんと理解する 2021/07/07 #4 atma勉強会 nyk510
質問です。
CORSって知ってますか?
CORS Cross-Origin Resource Sharing オリジン間リソース共有
名前ぐらいは聞いたことある? エラーで見たことはある? よくわかんない?けどなんかヘッダーに設定 したら直るやつ?
ちゃんと理解しましょう!
CORSの定義 追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブ アプリケーションに、異なるオリジン にある選択されたリソースへのア クセス権を与えるようブラウザーに指示するための仕組みです。
CORSの定義 追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブ アプリケーションに、異なるオリジン にある選択されたリソースへのア クセス権を与えるようブラウザーに指示するための仕組みです。
オリジンて何?
オリジン URLのプロトコルとホスト(ドメイン)、ポートで識別されるもの 全部が一緒だと同じオリジンとなる 例えば https://hoge.com に対して • 同じ: https://hoge.com/foo/bar.html /
https://hoge.com:443 • 違う: http://hoge.com / https://api.hoge.com
CORSの定義 追加の HTTP ヘッダーを使用して、 あるオリジンで動作しているウェブアプリケーション(ex: フロントエンド)に、 異なるオリジン にある選択されたリソース (ex: バックエンド)への
アクセス権を与えるようブラウザーに指示するための仕組みです。
CORSの定義からわかること • 特定のオリジンのアプリから、別のオリジンのデータ(リソース)を 取ってくる権限を定めたものである。 • ブラウザーの仕組みである ◦ 例えば terminal からのアクセスは関係ない
なんでこんなのがあるの? • セキュリティ的観点から同じオリジン以外の情報を取ってこれないようにしてい るから • 取ってこようとしている先のオリジンが許可した時だけデータのやり取り(リソー ス共有)ができるホワイトリスト方式になっている。 以下の説明では • ブラウザで表示されているオリジン:
Alice • 異なるオリジン: Blob として説明します。
ブラウザは、どうやって許可されているかを知るの? • ブラウザは一度普通にBobへとリクエストを送りBobはレスポンスを返す • ブラウザはレスポンス内の Access-Control-Allow-Origin ヘッダーをみる ◦ リクエスト元の Origin
がこの中に入っていれば許可されたとみなす。 ◦ ワイルドカード * 指定も出来る。この場合何でも許可されたとみなす。 ◦ それ以外は許可されていないリクエストとみなす。 • 許可されている時 ◦ レスポンスを展開して js からアクセス可能 • 許可されていない時 ◦ ブラウザが強制的に処理を止めてエラーになる. js からは「何かしらのエ ラーが起こった」しかわからない(これはセキュリティのため)
Bob から見ると… • 自分を呼び出してもオッケーなサイトを Access-Control-Allow-Origin に入れる • するとそれ以外のオリジンでは、ブラウザからBobの情報を参照できない • すくなくともブラウザでアクセスして悪さする外部サイトの脅威を減らせて良い
アクセス許可の方法 • 単純リクエスト • プリフライトリクエスト
単純リクエスト • 相手サーバ Bob に副作用を起こさないようなリクエスト • 先のフローと同様のやり方で許可を判定する • method: GET/HEAD/POST
• content-type: application/x-www-formurlencoded, multipart/form-data, text/plan
プリフライトリクエスト • 単純リクエストでないものが該当 ・ ex:) POSTで json を送りたい フロー •
許可を取るリクエスト (OPTION) を自動的にブラウザが Bob へ送信 ◦ 今からこういうことするのでオッケーですかというお伺い ◦ これがプリフライトリクエスト • Bobは要求に従って何を許可するかを返信 ◦ ex). POSTはOK / application/json はOK • ブラウザは許可内容をみる (Bobは何がOKって言っている?) ◦ やりたいリクエストが許可なら、Bobへ本体のリクエストを送信 ◦ 許可されていなければエラーにする(jsからは失敗内容はわからない)
ブラウザからのリクエストとレスポンス • 何故か method が単数形と複数形あるがこれはお伺い建てるのはひとつだけだから • リクエストだけ origin は origin
なのは謎 要求 リクエストヘッダー レスポンスヘッダー methodに対する許可 Access-Control-Request-Method Access-Control-Allow-Methods ヘッダーに対する許可 Access-Control-Requests-Header Access-Control-Allow-Headers オリジンに対する許可 Origin Access-Control-Allow-Origin
具体例を見ましょう。
例: ぐるぐる フロントエンド: https://guruguru.science バックエンド: https://api.guruguru.science これらは別 Origin なので Access-Control-Allow-Origin
をバックエンド 側に仕込んでいないとフロントをブラウザで開いた時バックエンドの情 報は表示できない。
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ ブラウザからAPIへ送信して いるリクエストヘッダー APIからブラウザへ返信され たレスポンスヘッダー
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ リクエストの method が GET なので 単純リクエストとしてブラウザで処理される。
例: ぐるぐる・単純リクエスト https://api.guruguru.science/competitions/17/ APIが allow-origin に www.guruguru.science を入 れている →
ブラウザで表示OK
例: ぐるぐる・プリフライトつきリクエスト ログインページ: https://api.guruguru.science/auth/login/ POSTでかつusername/passwordを送信するため単純ではない。 おさらい • はじめOPTIONによるプリフライトで確認 • 確認がとれれば本体のPOSTを送信
例: ぐるぐる・OPTIONによるプリフライトで確認 ブラウザはこれから何を送ろうとしているかをOPTION をつかってお伺い (プリフライトリクエスト) この場合だと 「MethodはPOST / ヘッダーには content-type
/ オリ ジンは https://www.guruguru.science ですがよろしい でしょうか」
例: ぐるぐる・OPTIONによるプリフライトで確認 APIはブラウザの各種 requests に対して何を許可 しているかを返す。 API「POSTはOK・ヘッダーも content-type は オッケーで、オリジンもOKだよ!」
例: ぐるぐる・確認がとれれば本体のPOSTを送信 今回の場合別オリジン(API)から許可がもらえたの で本体のPOST処理を送信。 もう許可はもらえているのでこのリクエストに Access-Control-Request 系のヘッダーはない。
まとめ • CORSはオリジンの違うサーバにたいしてブラウザからアクセスするときの制御に 関する仕組みである。 • リクエストの種類によってプロトコルが異なる。
参考資料 • https://developer.mozilla.org/ja/docs/Web/HTTP/CORS • 安全なウェブアプリケーションの作りかた・3.3章