ネットワークCookie、クロスソースリソース共有(CORS)

<기초부터 완성까지 프론트엔드>를 읽고 정리한 내용입니다.

クッキー

HTTP Cookieは、サーバがユーザWebブラウザに送信する記録情報ファイルである.無状態のHTTPでは,ブラウザがCookie情報を記録し,再要求したCookie情報を一緒に同じサーバに送信する.公開された情報なのでセキュリティが悪い.Webストレージなどの情報を格納するリポジトリが追加され、必要に応じて選択できます.名前-値で情報を記録し、Cookieの有効期限、ドメイン、セキュリティ、HttpOnlyなどの情報を記録します.
サーバから送信されたHTTP応答のSet-Cookieヘッダを使用してCookieを作成

HTTP/ 1.1 200 OK
Content-type: text/ html
Set-Cookie: cookie1=value1
Set-Cookie: cookie2=value2

応答による2つのCookieプロパティの作成と保存

GET/ page.hmlt HTTP 1.1
Host: ...
Cookie: cookie1=value1; cookie2=value2

Cookie値をサーバに送信されたすべてのリクエストに返信

ツールバーの

Cookieの削除
Cookieはセッション終了時に削除されます.Expriesプロパティに日付が含まれている場合、またはMax-ageで期間(秒)が指定されている場合は、削除されます.Max-ageが優先されます.

クランクレンズ
DomainプロパティとPathプロパティを使用すると、CookieにアクセスするドメインとURLのパスを設定できます.

ドメインが指定されていない場合:現在のドキュメントの場所に基づいてサブドメイン

が含まれる.

パスを指定すると、対応するURLパスとサブディレクトリパスからCookieにアクセスできます.

Secure, HttpOnly
デフォルトでは、Cookieはプロトコルではなくドメインに基づいています.Cookieは、Secureプロパティの使用時にHTTPS通信を使用する場合にのみ送信されます.
HttpOnlysはCookieをクライアントで使用できないようにします.document.クライアントがJavaScript(クッキーなど)を使用してクッキーにアクセスすることを阻止

document.cookie

現在登録されているサイトに関するCookie情報を知ることができます.

document.cookie="name=jungin; path=/;"

1つのCookieが消費する容量は4 KBで、ブラウザによって許可されているCookieは約20個程度です.

ソース間リソース共有

両方のURLのプロトコル、ポート、ホストが同じ場合は、同じソースと呼ばれます.

ex) http://a.test.com:80/docs
=> http://a.test.com:80/write  동일 출처 (o)
=> http://b.test.com:80/tutorial 동일 출처 (x) 호스트가 다름

同じソースポリシー(Same Origin Policy,SOP)は、1つのソースからロードされたドキュメントまたはJavaScriptが他のソースのリソースと相互作用することを制限するセキュリティ方式です.2つのURLのソース(Origin)が異なる場合は、単独で処理する必要がなく、APIサーバの応答を受信できません.
ブラウザのセキュリティを確保するために、同じソースポリシーでは、潜在的に危険なドキュメントへのアクセスは許可されません.従来,Webサーバが要求を処理し,結果を静的ページに下げることは大きな問題ではなかったが,外部APIサービスの利用,クライアントとAPIサーバを分離してウェブサイトを作成するなどのウェブサイト機能や役割の増加に伴い,これらのポリシーが問題となり始めた.
この問題を解決するために、HTTPヘッダが追加され、CORSは、そのヘッダを使用してアプリケーションが他のソースのリソースにアクセスできることをサーバに伝えることができます.

CORSは、要求ヘッダのOriginフィールドをサーバから送信されたアクセス制御Allow-Originと比較し、ブラウザでこの応答が有効かどうかを判断した後、無効であれば応答をエラーとして処理します.最も一般的なシナリオは、プリリクエスト方式です.

単純なリクエスト

次のすべての条件を満たすリクエスト:
次のいずれかの方法があります.

GET

HEAD

POST

ユーザエージェントが自動的に設定するタイトルのほか、手動で設定できるタイトルのみ
Fetchリストに「CORSセキュリティリスト要求ヘッダ」と定義されているタイトル
それだけです.

Accept

Accept-Language

Content-Language

2Content-Type(以下の追加要件に注意してください)

Content-Type次の値のみが許可されます.

application/x-www-form-urlencoded

multipart/form-data

text/plain

リクエストで使用されたXMLHttpRequestUploadオブジェクトは、イベントリスナーを登録していません.これらはXMLHttpRequest.uploadパーセントで近い.
要求はReadableStreamオブジェクトを使用しません.

クライアントとサーバ間で簡単な通信を行い、CORSヘッダ処理権限を使用する
ブラウザは、サーバに送信されたコンテンツを表示し、サーバの応答を確認します.
アクセス-コントロール-すべてのOrigin:*はすべてのドメインにアクセスできることを示します.

プリリクエストモード

プリリクエスト方式は,クロスサイトリクエストがユーザデータに影響を与える可能性があるため,OPTIONS HTTPメソッドを用いて実際のリクエストを送信する前に,セキュリティリクエストであるかどうかの許可を得てから実際のリクエストを送信する方式である.通常、ブラウザで自動的に転送されます.

ブラウザが実際のPOST要求を送信する前に、ドメインのPOSTメソッドを許可するかどうかを尋ねる事前要求が送信される.Access Control Allow-originは、サーバが許可するソースを教え、ブラウザがリソースにアクセスできるかどうかを判断するために使用します.
サーバが要求を許可すると、「アクセス-制御-すべてのメソッド」フィールドに許可されたメソッドが表示され、「アクセス-制御-すべての-origin」フィールドに許可されたソースが表示されます.
事前依頼が終わったら、実際の依頼を送って回答を受けます.

認証情報を含むリクエスト

ブラウザが提供するXMLHTTPRequestまたはfetch()は、ソースが異なる場合、ブラウザのCookieまたは認証情報をタイトルに含めません.要求に認証情報を含める場合は、credentialsオプションを変更する必要があります.全部で3つの値があります.

同一ソース:同一ソースの場合、

が送信される.

省略:Cookie

は、同じソースから来るかどうかにかかわらず、常に送信されない.

include:クロスソースでも

を送信credentialsがincludeの場合、サーバはAccess-Control-Allow-Originをワイルドカード(*)に設定し、要求は失敗します.これは、信頼できるソースを明確に決定する追加のセキュリティ対策です.したがって、ワイルドカードではなく明確なURLを指定する必要があります.
要求が正常に処理された場合、応答はAccess-Control-Allow-Credentialをtrueとして返し、ヘッダが含まれていない場合、応答は無視される.

シングルラインサマリー

CORSは、追加のHTTPヘッダ認証アプリケーションを使用して、他のソースのリソースにアクセスする方法です.
リファレンス
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS