{
  "$type": "site.standard.document",
  "canonicalUrl": "https://blog.nove-b.dev//posts/cors-why-domain-restriction",
  "path": "/posts/cors-why-domain-restriction",
  "publishedAt": "2023-07-28T00:00:00.000Z",
  "site": "at://did:plc:2atly2y5kfyjcj5zap6pv4wd/site.standard.publication/3mmxeqr2tcb2k",
  "tags": [
    "ドメイン",
    "浅く理解した",
    "cors"
  ],
  "textContent": "本記事は不確かな情報が多く含まれる可能性がある\n\n本職はフロントエンドエンジニアで、基本的に取得した情報に色をつけ表示させることで会社内での居場所を維持してきた。\n\nただ最近個人開発でバックエンドに触れることが増えセキュリティにも興味が出てきた。\n\nただ、まだまだ浅い理解しかない。\n\n何が言いたいかというと、この記事は不確かな情報を含んでいる可能性があるということ。\n\n浅く理解したくなったきっかけ\n\n最近、個人開発ということでNestJSでAPIを作成した、\n\n作成したAPIをLambdaに乗せ、カスタムドメインを設定せずに使用している。\n\nそのため、CORSのクロスオリジンを指定する必要があった。\n\nNestJSは一行ですべてのドメインに対しCORSを許可することができる。\n\n開発環境ではそれでいいが、本番で運営するにあたり、許可するドメインを指定する必要がありそうだということを調べて知った。\n\nしかし、なぜ？ という疑問が生じた。\n\nいくら絞ったところでcurlコマンドで叩けるので別に絞る必要がないのでは？\n\nという疑問を解決するために調べてみた。\n\nCORSを指定しないことで考えられるセキュリティリスク\n\nクロスサイトリクエストフォージェリ（CSRF）攻撃\n\nCSRFは悪意のある攻撃サイトにユーザーが訪問した際、意図しないリクエストがCSRFの脆弱性のあるウェブアプリケーションに投げられ、設定の変更や、強制投稿が行われるということ。\n\nCSRF(Cross-Site Request Forgery)攻撃について\n\nこのサイトが非常に参考になった。\n\nCORSで防げる\n\nこのサイトにあげられている下記のようなポイントのうち、\n\n> 対象のWebサイトのユーザが、正規の手順でログイン済であることを前提とする\n\n> 対象のWebサイトが、設計上意図しない更新操作を受け付けてしまうことで攻撃が成立する\n\n「対象のWebサイトが、設計上意図しない更新操作を受け付けてしまうことで攻撃が成立する」をCORSの設定で防ぐことができる。\n\n悪意のあるサイトのドメインがCORSで許可されていなければ、いくらリクエストが飛ばされたところで問題ない。\n\nそのため、CORSのドメインは信頼されたドメインに絞り込む必要がある。\n\nそういうこと。",
  "title": "CORSでクロスオリジンの設定をする際に、なんでドメインを絞り込む必要があるのか浅く理解した"
}