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
380
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.2k
Django のセキュリティリリースを見る
nyk510
0
76
3分でMLアプリを作る 〜推論コードにちょっとのStreamlitを添えて〜
nyk510
1
1.1k
硬派で真面目なグラフを描く
nyk510
0
500
pythonで気軽にパッケージを作るのは良いという話。
nyk510
14
9.5k
RestAPIのページネーション atma バックエンド勉強会 #3
nyk510
1
920
AWS CPU Credit を完全に理解する
nyk510
0
440
atmaCup#8 Opening
nyk510
0
240
オンサイトデータコンペの魅力: 関わる全員が楽しいコンペ設計のための取り組み
nyk510
3
5.3k
Other Decks in Technology
See All in Technology
Would you THINK such a demonstration interesting ?
shumpei3
1
220
CodePipelineのアクション統合から学ぶAWS CDKの抽象化技術 / codepipeline-actions-cdk-abstraction
gotok365
5
180
AIコーディングの最前線 〜活用のコツと課題〜
pharma_x_tech
3
1.5k
Cursor AgentによるパーソナルAIアシスタント育成入門―業務のプロンプト化・MCPの活用
os1ma
13
4.7k
Amazon CloudWatchで始める エンドユーザー体験のモニタリング
o11yfes2023
0
190
LiteXとオレオレCPUで作る自作SoC奮闘記
msyksphinz
0
640
フロントエンドも盛り上げたい!フロントエンドCBとAmplifyの軌跡
mkdev10
2
280
CBになったのでEKSのこともっと知ってもらいたい!
daitak
1
160
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
610
4/17/25 - CIJUG - Java Meets AI: Build LLM-Powered Apps with LangChain4j (part 2)
edeandrea
PRO
0
110
読んで学ぶ Amplify Gen2 / Amplify と CDK の関係を紐解く #jawsug_tokyo
tacck
PRO
1
140
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
1
570
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Bash Introduction
62gerente
611
210k
Code Review Best Practice
trishagee
67
18k
Code Reviewing Like a Champion
maltzj
522
40k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
BBQ
matthewcrist
88
9.6k
Making Projects Easy
brettharned
116
6.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
119
51k
Automating Front-end Workflow
addyosmani
1369
200k
Producing Creativity
orderedlist
PRO
344
40k
Thoughts on Productivity
jonyablonski
69
4.6k
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章