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完全に理解した(したい)
Search
toshi00
August 28, 2023
Programming
0
5
CORS完全に理解した(したい)
CORSについて簡単に紹介する資料です
https://github.com/toshi-pono/CORS-practice
toshi00
August 28, 2023
Tweet
Share
More Decks by toshi00
See All by toshi00
aiotraQで爆速BOT開発!
toshi00
0
19
Rustで エンジニアは絶対に使えない「TypoIME」を作ろう
toshi00
0
690
JtagAdapter制作記 seccamp2021 X-2 / jtagAdapter
toshi00
0
160
Other Decks in Programming
See All in Programming
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
36
11k
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
180
iOS開発スターターキットの作り方
akidon0000
0
230
kiroでゲームを作ってみた
iriikeita
0
140
MCP連携で加速するAI駆動開発/mcp integration accelerates ai-driven-development
bpstudy
0
250
中級グラフィックス入門~効率的なメッシュレット描画~
projectasura
4
2.4k
PHPカンファレンス関西2025 基調講演
sugimotokei
6
1.1k
LLMは麻雀を知らなすぎるから俺が教育してやる
po3rin
3
1.9k
decksh - a little language for decks
ajstarks
4
21k
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
710
Comparing decimals in Swift Testing
417_72ki
0
160
抽象化という思考のツール - 理解と活用 - / Abstraction-as-a-Tool-for-Thinking
shin1x1
1
930
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
332
22k
Side Projects
sachag
455
43k
Typedesign – Prime Four
hannesfritz
42
2.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
870
The Cult of Friendly URLs
andyhume
79
6.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.5k
Statistics for Hackers
jakevdp
799
220k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Invisible Side of Design
smashingmag
301
51k
Transcript
CORS完全に理解した(したい) @toshi00_p 2023.08.28
今⽇やること たまによくあるエラー CORSでブロックされた!ってときに何が起きてるか ちょっとだけ理解する CORSと仲良く開発しよう! 2/17
今⽇やること CORS:オリジン間リソース共有 1. オリジンとは? 2. CORSの仕組み 3. CORSの必要性 扱わないこと •
プリフライトリクエスト • HTMLタグ内でのリクエスト(img, iframe, canvasなど) • Cookie 3/17
CORS = オリジン間リソース共有、 Cross-Origin Resource Sharing 4/17 CORSとは クロスオリジンのときに
リソースを使えるようにする サーバーからブラウザへの許可 APIリクエストと そのレスポンス オリジンが違う 同⼀オリジンのリクエストは常に許可 クロスオリジンのリクエストは基本は禁⽌ → (でもアクセスしたい)→ CORSで個別に許可 許可に応じて ブラウザが制御
CORS = オリジン間リソース共有、 Cross-Origin Resource Sharing 5/17 CORSとは クロスオリジンのときに
リソースを使えるようにする サーバーからブラウザへの許可 APIリクエストと そのレスポンス オリジンが違う 同⼀オリジンのリクエストは常に許可 クロスオリジンのリクエストは基本は禁⽌ → (でもアクセスしたい)→ CORSで個別に許可 許可に応じて ブラウザが制御
1. クロスオリジン? 6/17 オリジンとは https://example.com:443 host name port scheme リクエスト元
リクエスト先 https://example.com https://example.com same-origin: 完全一致 https://dev.example.com cross-origin: サブドメイン https://example.com:8080 cross-origin: 異なるポート オリジン = スキーム(プロトコル) + ホスト名 + ポート
1. クロスオリジン? 7/17 (おまけ) origin と site 対象:https://example.com same-origin same-site
same-site かどうかは cookie の送信で関係してくる same-site: eTLD+1が同じ(雑に書くと、ドメインの持ち主が同⼀) https://example.com https://example.com:443 https://github.com https://google.com http://example.com https://dev.example.com https://example.com:8080
CORS = オリジン間リソース共有、 Cross-Origin Resource Sharing 8/17 CORSとは クロスオリジンのときに
リソースを使えるようにする サーバーからブラウザへの許可 APIリクエストと そのレスポンス オリジンが違う 同⼀オリジンのリクエストは常に許可 クロスオリジンのリクエストは基本は禁⽌ → (でもアクセスしたい)→ CORSで個別に許可 許可に応じて ブラウザが制御
2. CORSの仕組み 9/17 JSエンジン*¹ ブラウザ サーバー *1: 実際には、JSエンジンはブラウザの内部に組み込まれている *2: 単純リクエストでない場合は、許可がなければリクエストも送信しない
リクエストの送信を要求 レスポンス 許可されて いなければ 破棄 レスポンス リクエストを送信*² フロントエンド開発 バックエンド開発
2. CORSの仕組み 10/17 CORSのヘッダー ※ 許可の申請(クライアントからサーバー)はブラウザが自動でやってくれる。FE側でやることは特にない。 許可(サーバーからクライアント) • Access-Control-Allow-Origin •
Access-Control-Allow-Credentials • Access-Control-Allow-Headers • Access-Control-Allow-Methods • Access-Control-Expose-Headers • Access-Control-Max-Age 許可の申請(クライアントからサーバー※) • Origin • Access-Control-Request-Headers • Access-Control-Request-Method
2. CORSの仕組み(許可の例) 11/17 Access-Control-Allow-Origin JSエンジン JSエンジン https://site.example https://evil.example https://api.example Access-Control-Allow-Origin:
https://site.example 許可したオリジンのみレスポンスを取得できる
2. CORSの仕組み(許可の例) 12/17 Access-Control-Expose-Headers JSエンジン JSエンジン https://site.example https://site.example https://api.example Access-Control-Expose-Headers:
Myheader CORSセーフリストレスポンスヘッダーは、許可なしに取得できる (Cache-Control, Content-Length, Content-Language, Content-Type, Expires, Last-Modified, Pragma) Myheader: hogehoge Myheader: undefined 許可あり 許可なし
3. CORSの必要性 13/17 CSRF脆弱性 今回のケースはCookieの設定も良くない……かも なお、CORSだけでは防げないパターンもあるので注意が必要 https://api.example https://site.example https://evil.example ログイン:
Cookieがapi.exampleに 対して付与 ①ログイン ②アクセス ③勝手に リクエスト ④レスポンス ⑤レスポンスを覗 き見 CORSがないので リクエストできる
CORS = オリジン間リソース共有、 Cross-Origin Resource Sharing 14/17 CORSとは クロスオリジンのときに
リソースを使えるようにする サーバーからブラウザへの許可 APIリクエストと そのレスポンス オリジンが違う 同⼀オリジンのリクエストは常に許可 クロスオリジンのリクエストは基本は禁⽌ → (でもアクセスしたい)→ CORSで個別に許可 許可に応じて ブラウザが制御
終わりに CORSで重要なポイント Origin Access-Controll-Allow-Origin 単純リクエスト プリフライトリクエスト CORS完全に理解した!(わからん) 15/17
参考 • オリジン間リソース共有 (CORS) https://developer.mozilla.org/ja/docs/Web/HTTP/CORS • フロントエンド開発のためのセキュリティ⼊⾨ 16/17