CORS

(1) CORS
Cross-Origin Resource Sharing
CORS는 HTTP의 일부로, 어떤 호스트에서 자신의 컨텐츠를 불러갈 수 있는지 서버에 지정할 수 있는 방법
리소스가 자신의 출처(Domain, Protocol, Port)와 다른 교차 출처 HTTP 요청을 실행
보안 상의 이유로 브라우저는 교차 출처 HTTP 요청을 제한
CORS 정책은 우리가 가져오는 리소스들이 안전한지 검사하는 관문

(2) CORS : 해결법 (django)
Django CORS Headers 설치
- pip install django-cors-headers 

Django CORS Headers 설치 반영
- settings.py INSATLLED_APP에 ‘corsheaders’ 추가

Response 수신을 위한 middleware 추가
- settings.py MIDDLEWARE에 ‘corsheaders.middleware.CorsMiddleware’ 추가
- corsheaders 미들웨어를 추가할 때는 반드시 MIDDLEWARE 최상단에 위치시키도록 해야 함

Django에서 CORS 미들웨어의 대한 구성 설정
- CORS_ORIGIN_WHITELIST에 사이트 간 요청을 허용하는 호스트를 추가하거나 CORS_ORIGIN_ALLOW_ALL을 True로 설정하여 모든 호스트를 허용해야함
-

(3) 여전히 되지 않음 : 이유 ?
* 참고링크
https - > http의경우
소셜 로그인을 위해 https 프로토콜을 사용했었음.
header를 살펴보니,

strict-origin-when-cross-origin이 header로 들어가있었음.


same-site와 same-origin의 차이
* Origin :  scheme (protocol로도 알려진 : http,https..)와 host name, 그리고 port의 조합을 의미 (http://naver.com:(80 - 기본포트는 생략해도 ok))
* Site : 탑 레벨 도메인 (TLD), 즉 .com과 .org등은 Root Zone Database에 등록되어 있으며 site는 TLD와 domain의 조합을 의미. (port x, naver.com)

http 요청은 옵셔널 헤더인 Referer를 가지고 있을 수 있다.
이 정보는 이 요청이 만들어진 origin 또는 웹페이지 URL을 가리킴.

Referer 헤더는 다양한 형태의 요청에 존재할 수 있는데,
사용자가 링크를 클릭하는 네비게이션 링크라던지,
브라우저가 이미지, iframe, script 등 페이지에 필요한 리소스를 요청하는 subresource 요청 등이 있을 수 있다.

query와 path를 포함한 전체 주소를 Referer를 통해서 다른 origin에 보내는 것은, 보안 상에서 문제가 될 수 있으므로, Referrer-Policy에서 사이트의 요청에 사용할 수 있는 referer 데이터를 제한한다.

	No Data	Origin Only	Full URL
no-referrer	✔
origin		✔
unsafe-url			✔
strict-origin	HTTPS → HTTP	HTTPS → HTTPS, HTTP → HTTP
no-referrer-when-downgrade	HTTPS → HTTP		HTTPS → HTTPS, HTTP → HTTP
origin-when-cross-origin		cross-origin	same-origin
same-origin	cross-origin		same-origin
strict-origin-when-cross-origin	HTTPS → HTTP	cross-origin, HTTPS → HTTPS, HTTP → HTTP

이번 cors error reponse들의 header를 확인해 봤을 때, referrer-policy는 strict-origin-when-cross-origin이었다.

• strict-origin-when-cross-origin
  명시적으로 보안이 강화된 referrer policy .
  HTTP와 HTTPS에 대해 차이를 두고 있지 않다