---
# System prepended metadata

title: 2021/01/31 メンター相談
tags: [1月, メンター相談]

---

# 2021/01/31 メンター相談

[元URL]https://hackmd.io/@HideoKaizuka/HJEMKVMld

質問
---
1. [「シンプルなリクエスト」の条件でなぜPOSTが「許可されているメソッド（`CORS安全とされるメソッド`）」に含まれるのでしょうか？ `安全なメソッド` との違いが気になりました。](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recrX6aFwd411uMxb)
解答
SOPとCORSは後からできたから。
FetchStandardからhttps://fetch.spec.whatwg.org/
HTMLのformリクエストでできることは安全とされている。
formでできないことをやる時にプリフライト。



1. [「シンプルなリクエスト」の条件でなぜ以下のようなヘッダーが許可されているのでしょうか？反対に、どのようなヘッダーが含まれていると危険ですか？](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recBlvYbqxoFpH8YC)
解答
DPRから下はクライアントヒントという分類のヘッダー。サーバーへのヒント。便利機能として存在してるヘッダーは悪さはしないので許しても問題なさそう。
上の4つは昔からあるやつなので。
HTMLフォームからjsonは送れる？
https://www.w3.org/TR/html-json-forms/
HTTPヘッダーで悪さするみたいなことはない。
CORSはわかってる人のみに安全に使ってもらうという思想。


1. [各ブラウザの仕様を調べるとき、どのようにして調べていますか？](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recbCRqMG0o2VsNGW)
解答
ブラウザの仕様でしか考えられないバグとかの時に探す。
上から辿ることはせずに、気になったワードを調べるくらい。
各ブラウザのリリース情報を見にいく。ブラウザも開発者に影響がある場合は丁寧に解説してくれてる。
「クッキー　ブラウザ　違い」とかで調べて、スタックオーバーフロー、そこからさらに調べる。
ブラウザのキャッシュの仕様を調べる問題では、キャッシュは削除されるものとして認識して欲しいという意図がある。


1. [CORSの通信で資格情報を付けた通信を行う際は、なぜAccess-Control-Allow-Credentials の設定を別途行う必要があるのでしょうか？](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recKyCDaVzsniRiUn)
解答
CORSはわかってる人のみに安全に使ってもらうという思想。
Access-Control-Allow-Credentialsはサーバー側。サーバもクライアントも両方わかっていて、コントロールできる状態の時に許可して欲しいという思想のもと。オリジンは厳密にセットする方が安全。


1. [サーバー側はNginx側だけにCORS設定を行えば問題ないという理解で合っていますでしょうか？](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recrJ1z82pI89gwpZ)
解答
その通り。同じNginxとアプリでネットワークにあることが多い。また、別のネットワークでも、サーバ同士の通信はCORSの範囲外。


1. [リバースプロキシとアプリケーションサーバー間のCookieの共有はどうされているのでしょうか？](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec165edvKObmRaod)
解答
デフォルトでは共有される。
cookieのドメイン属性はブラウザが気にしている情報。wwwの有無を変更している例が出ているが、これをわざわざやることはあまりない。DNSのCNAMEでやることが多い。

1. [「シンプルなリクエスト」でPOSTした場合、サーバーへのリクエストが送れてしまうため、データの登録が出来てしまう気がするのですが、何か対策は必要なのでしょうか？(クッキー等で認証 + CSRF 対策があれば十分なのか？)](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recArBa54CjyPbZB1)
解答
その通り。シンプルなリクエストはプリフライトリクエストかは許可されていないユーザへのアクセスを制御するのに関係するわけではない。他にも対策が必要(クッキー等で認証もしくはCSRF 対策)。
SPAでのform xmlhttpリクエスト、fetchAPIかaxiosは基本的にはapplication/jsonでデータを送るためpreflight requestが生じる。よりデータをセキュアに扱うために、cookieにトークンを付けて送る。expressのmiddlewareで認証を書くことが多い。

1. [サードパーティクッキーを受け取る実装で、ngrokのドメイン(localhost:3000)からのクッキーを受け取るようにimgタグを用いた実装を行ったのですが、
ChromeのDev ToolsのApplicationタブで確認したところ、ngrokのURLが表示されませんでした。](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec30WTAvwTmwX92M)
解答
クロームのcookieタブについて。
iframeは全く別のサイトを開いてる状態。
cookieが8081にセットされるのでなく、iframeのサイトにcookieにセットされる。


その他
---

1. キャッシュのブラウザの仕様調べる時について
https://source.chromium.org/chromium/chromium/src/+/master:net/disk_cache/cache_util.cc;l=87?q=defaultCacheSize&ss=chromium
上記のようにdefaultCacheSizeは色々条件によって変わるようだが。。。
ここまでやらなくても大丈夫。少しググって出てくることくらいで大丈夫。
上限が超える時にブラウザによって仕様が変わる。

1. SPAのCSRF対策について、どのタイミングでトークンを埋め込む？
firebaseのSDKを使うことが多い。匿名ログインというのもある。
サーバ側にもfirebaseのSDKを入れ手認証する。
認証系にはfirebaseを使うことが多い。

1. fetchとaxiosを使っているか？
fetchはわかっている人だけちゃんと使ってねという感じで、自由に設定できる分、設定しなきゃいけないことも多い。axiosはよしなにやってくれることが多い。fetchはサーバ側が最近までなかったので、サーバ側と統一させるためにaxiosを使っていた。node-fetchがリリースされたことで、サーバ側でもfetchを使えるようになった。


###### tags: `メンター相談`,`1月`
