cors
ブラウザでオリジン間リソースを共有（Cross-Origin Resource Sharing）するための仕組み セキュリティ機能の一つではあるけど、こいつ自体がセキュリティ機能っていうべきではない気もする。
リクエストするのが同一のオリジンなら関係ないし気にしなくていいよ。 nextjsのapp routerとかだと/apiでアクセスできるけどああいうのは同一オリジンだからよくcorsの回避とかで出てくるよ
レスポンスをjsで読み取るかどうかを制御する
まとめるとどういうもの？
簡単にいえば異なるオリジンではリクエストできない機能
リクエストできないではなく、レスポンスを読み取るとかjsからアクセスできないようにする仕組み
ブラウザの利用者がアクセスしてしまったときに、そこのjsからcookieとか取られないように同一オリジンのリソースにしかjsがアクセスできないようになってる。
iframeで他のサイト表示するとかも同一オリジンじゃないから防いでくれる
やばいよ！
主にサーバーのAPIを守るために設定するものって感じなんじゃないかな？
違うブラウザを利用している利用者を守るためのもの
Access-Allow-Control-Origin: * はこのcors無視して全てのクライアントからアクセスできてしまう
資格情報が必要な場合は使えないし、*にしてても悪いわけではないけどちゃんと理解して指定しろよって感じだと思う。
それだとAPIとフロントエンドのオリジンが違うとリクエストできなくなっちゃって困る
その機能を緩めてくれるのがcorsの役割
Corsってどういう原理で動いてんの？
ブラウザが異なるオリジンにリクエストする際、API側で返されるcorsの設定をみてリクエストするか、レスポンスを返すかを判断してくれる。
単純リクエストと非単純リクエストがある
APIリクエストするときにOriginを付与したりと色々ブラウザが実はやってたりする
何がどのリクエストに入るかはドキュメント読んで
ブラウザーがオリジンをまたいだリクエストのレスポンスに、フロントエンドの JavaScript コードがアクセスすることをブロックするかどうかを決めるものです
理解に役立ちそうなところ
クライアント（フロントエンド）、ブラウザ、サーバーの３者がいるって前提を持ってた方が良さそう
拒否するのはブラウザがサーバーのレスポンスをみて判断してるから
Tips
Cookieを扱う場合はOriginの指定が必須
資格情報を送りたい場合は、 axiosなどでwithCredentials: true、サーバーでもwithCredentialsをtrueにしてCookieのデータをクライアントから送信できるようになるが、AllowOriginがワイルドカードの場合は怒られる。 ここら辺はcorsの挙動なのかな。
ライブラリによっては設定を自動で作ってくれる
例えばexpressとかでapp.use(cors())ってやるけどそれをすると必要な指定とかをあらかじめ書いてくれてるって感じみたい。 詳しい実装みてないけど、preflightのリクエストする時のoptionsのハンドラーとかallow-controls系の指定を色々書いてくれるんかね。いつか実装みてみるわ
めも
もっとセキュリティに関して理解したいな
攻撃者が具体的にどういった考えで攻撃するのか、何を攻撃するのかそれをしれたらもう少しcorsのありがたさが理解できる気がする
ブラウザハックと、フロントエンドのセキュリティ入門って本買ったしいつか読みたい