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
990
Django のセキュリティリリースを見る
nyk510
0
34
3分でMLアプリを作る 〜推論コードにちょっとのStreamlitを添えて〜
nyk510
1
990
硬派で真面目なグラフを描く
nyk510
0
440
pythonで気軽にパッケージを作るのは良いという話。
nyk510
14
9.4k
RestAPIのページネーション atma バックエンド勉強会 #3
nyk510
1
790
AWS CPU Credit を完全に理解する
nyk510
0
400
atmaCup#8 Opening
nyk510
0
200
オンサイトデータコンペの魅力: 関わる全員が楽しいコンペ設計のための取り組み
nyk510
3
5.2k
Other Decks in Technology
See All in Technology
いまならこう作りたい AWSコンテナ[本格]入門ハンズオン 〜2024年版 ハンズオンの構想〜
horsewin
9
2.1k
事業者間調整の行間を読む 調整の具体事例
sugiim
0
1.4k
Gradle: The Build System That Loves To Hate You
aurimas
2
140
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
110
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
コンテンツを支える 若手ゲームクリエイターの アートディレクションの事例紹介 / cagamefi-game
cyberagentdevelopers
PRO
1
130
Shift-from-React-to-Vue
calm1205
3
1.3k
omakaseしないための.rubocop.yml のつくりかた / How to Build Your .rubocop.yml to Avoid Omakase #kaigionrails
linkers_tech
3
730
Product Engineer Night #6プロダクトエンジニアを育む仕組み・施策
hacomono
PRO
1
470
Emacs x Nostr
hakkadaikon
1
150
Forget efficiency – Become more productive without the stress
ufried
0
110
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
hryushm
14
3k
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
334
57k
Designing for humans not robots
tammielis
249
25k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing Experiences People Love
moore
138
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Faster Mobile Websites
deanohume
304
30k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
What's in a price? How to price your products and services
michaelherold
243
12k
YesSQL, Process and Tooling at Scale
rocio
167
14k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
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章