[Web]CORS


SOP


Same Origin Policy(同じソースポリシー)は、任意のソースからロードされたドキュメントまたはスクリプトが他のソースからインポートされたリソースと相互作用することを制限する重要なセキュリティ方法です.同じソースポリシーを使用すると、有害なドキュメントが隔離され、攻撃を受ける可能性のあるパスが減少します.
「同一ソース(同一ソース)」とは?
👉 URLのプロトコル、ホスト、ポートで同じソースか異なるソースかを判断できます.
日本帝国主義http://localhostと同じ出所なのは?
1. https://localhost
2. http://localhost:80
3. http://127.0.0.1
4. http://localhost/api/cors
👉 2日4日です.
1番:プロトコルが異なる
2番:httpのデフォルトポートは80です
3番:string valueが異なるため、ブラウザは他のソースとして認識します.
4番:/api/corsはlocationなのでソースは同じです
✔httpのデフォルトポート:80、httpのデフォルトポート:443
他のソースのリソースが必要な場合はどうすればいいですか?
👉 他のソースの資源と相互作用するために、SOPの例外条件の下でのCORS政策が現れた.CORSポリシーに違反しなければ、他のソースのリソースを共有できます.

CORS


クロスソースリソース共有(Cross-Origin Resource Sharing,CORS)は、追加のHTTPヘッダ通知ブラウザを使用して、あるソースで実行されるWebアプリケーションが別のソースから選択されたリソースにアクセスできるようにするメカニズムです.Webアプリケーションは、リソースがソース(ドメイン、プロトコル、ポート)と異なる場合に、クロスソースのHTTP要求を発行します.
どのように徳州がCOS政策に違反したと判断しますか?
👉 比較ソースの論理は、サーバではなくブラウザに反映されます.
要求されたリソースがCORSポリシーに違反した場合、サーバの論理が同じソースのみを受け入れる場合を除き、サーバは正常に応答します.
その後、ブラウザが応答ヘッダを解析し、CORSポリシーに違反していると判断した場合、この応答は使用されません.

Request header / Response header


リクエストヘッダ

  • Origin:要求を送信するページソース(ドメイン)
  • アクセス制御要求方法:実際の要求方法
  • アクセス制御要求リーダ:実際の要求に含まれるタイトル名
  • レスポンスヘッダ

  • Access-Control-Allow-Origin
    要求を許可するソース
  • Access-Control-Allow-Credentials
    お客様がCookieによる資格取得を要求する場合、true
  • Access-Control-Allow-Methods
    要求を許可する方法で、デフォルトはGET、POSTです.このヘッダがないのは、GETおよびPOST要求
  • のみである.
  • Access-Control-Allow-Headers
    要求を許可するヘッダ
  • Access-Control-Max-Age
    クライアントがpreflightリクエスト結果を保存する期間を指定します.この期間中、preflightリクエストは二度と発行されません.
  • COSアクセス制御方式


    Preflight Request



    preflightとは、ブラウザがこの要求を送信する前に発行する代替要求であり、HTTP METHODでOPTIONSを使用する.
    プリリクエストは、このリクエストを送信する前に、ブラウザ自身がセキュリティリクエストであるかどうかを確認するプロセスです.

    Simple Request



    簡単な要求はサーバにAPIを要求し、サーバはブラウザに応答を送信し、アクセス制御Allow-Originヘッダを含む.ブラウザは、Access Control Allow-OriginヘッダをチェックしてCORS操作を実行するかどうかを判断します.
    代替要求がない場合に直ちにこの要求を発行すると、条件が非常に厳しいため、この要求はめったに発生しません.
    単純なリクエストをすると、リクエストを一度に終了し、なぜPreflightリクエストが必要なのでしょうか.
    👉 CORSを知らないサーバーに必要です.
    🤷‍♀️ 例
    👎 CORSが設定されていないサーバと簡単なリクエスト.
    CORS設定がないため、allow-sorigin->ブラウザはチェック後にクライアントにCORSエラーを通知します->クライアントからサーバへのリクエストがgetではなくdeleteの場合、サーバの観点からデータが変更される可能性があります(DB)
    👍 CORSのサーバとpreflightリクエストが設定されていません.
    サーバにallow-originがないため、ブラウザはクライアントにCORSエラーを発生させます->これは事前要求なので、サーバは何もしません->クライアントはCORSエラーを受信しているので、以下の実際のリクエストは発行されません->サーバは安全です.

    Credential Request


    認証関連タイトルを含むときに使用するリクエスト.
    クライアント資格証明:include
    fetch(url, {
      credentials: 'include', // 요청에 인증과 관련된 정보를 포함하겠다.
    });
    ❗ただし、credition:includeを使用すると、ブラウザではAccess-Control-Allow-Origin:*などのワイルドカードの使用は許可されません.
    サーバ側アクセス-制御-すべての認証情報:true
    「アクセス-コントロール-すべてのOrigin」では、*は使用できません.明示的なURLでなければなりません.