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
340
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
35
3分でMLアプリを作る 〜推論コードにちょっとのStreamlitを添えて〜
nyk510
1
1k
硬派で真面目なグラフを描く
nyk510
0
450
pythonで気軽にパッケージを作るのは良いという話。
nyk510
14
9.4k
RestAPIのページネーション atma バックエンド勉強会 #3
nyk510
1
800
AWS CPU Credit を完全に理解する
nyk510
0
400
atmaCup#8 Opening
nyk510
0
200
オンサイトデータコンペの魅力: 関わる全員が楽しいコンペ設計のための取り組み
nyk510
3
5.2k
Other Decks in Technology
See All in Technology
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
2
450
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
B2B SaaSから見た最近のC#/.NETの進化
sansantech
PRO
0
860
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
180
Platform Engineering for Software Developers and Architects
syntasso
1
520
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
複雑なState管理からの脱却
sansantech
PRO
1
150
AI前提のサービス運用ってなんだろう?
ryuichi1208
8
1.4k
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
170
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
290
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
A Tale of Four Properties
chriscoyier
156
23k
What's new in Ruby 2.0
geeforr
343
31k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Agile that works and the tools we love
rasmusluckow
327
21k
How GitHub (no longer) Works
holman
310
140k
Building Applications with DynamoDB
mza
90
6.1k
Adopting Sorbet at Scale
ufuk
73
9.1k
Typedesign – Prime Four
hannesfritz
40
2.4k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Code Reviewing Like a Champion
maltzj
520
39k
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章