CORS ?
다른 도메인(domains (en-US))에서의 자원을 호출하는 행위에 제한이 없을 경우 안전하지 않다. CORS (Cross-Origin Resource Sharing)는 이렇게 시스템 수준에서 타 도메인 간 자원 호출을 승인하거나 차단하는 것을 결정하는 것이다.
등장 배경
기존 클라이언트가 요청을하면 서버에있는 데이터를 유저가일방적으로 볼 수있는 방식이었음. 서버에 유저가 해를 가한다는 의심의 여지가 없었다.
하지만 여러곳에 있는 리소스를 활용할 필요가 생김 ( 유투브 api, 슬랙, 날씨 기타등등)
과 웹이 고도화 됨에 때라 CORS(Cross-Origin Resource Sharing) 리소스 서버지원을 요청하여 쓴다.
(깃허브에서 코드스테이츠, 깃허브에서 벨로그 ..)
현황
하지만 보안상의 이유로 브라우저는 크로스오리진요청을 제한하고있음. 우리서버에 어떤요청을 할지, 서버에 어떤 리소스를 생성하게될지 확인할 수가 없어서 애초에 막혀있는 상황임.
웹 애플리케이션을 고도화 위해 개선을 요청 , '서버가 허용한 범위' 내에 요청이 다시 가능해졌다.
서버에서 Allow 하는 조건들을 다 맞추고있는가 ?
(특정 도메인의 요청에 허용을 해준다면)
사전에 서버에 확인하는 요청이다.
(허가를 받은다음 GET/POST 를 해준다.)
CORS를 판별하는 3가지 기준은 ?
오리진은 프로토콜,호스트(도메인),포트번호 세가지에 의해 결정된다.
서버는 물리적으로 같을진 모르더라도 포트번호가 다름에 따라 다른 서버가 될수 있다.
한편, 쿠키와 로컬스토리지는 도메인에만 바인딩 되어있다. 도메인이 같아야 쿠키가 계속 유지된다.
도메인과 서브도메인
CORS 오리진은 보안관련이슈로, 프로토콜과 포트도 같이 바인딩되어있다.
예를들어 '쿠팡'에 접속한 상태에서 '쿠팡'의 '장바구니'로 들어가면, 도메인 주소가 https://www.coupang.com/ 에서 https://cart.coupang.com/cartView.pang 로 바뀜을 알 수있는데, 이것으로 우리는 '오리진'이 바뀜을 알수있다. '서브도메인'이 바뀌었기 때문이다.
하지만 쿠키는 공유가 되는 까닭은 쿠키의 path에서 path=/ 를 지정함에 따라 모든 쿠키를 받아올 수있기때문이다. 이렇게 설정한다면, '도메인'과 '서브도메인'이 달라도 쿠키를 받아올수 있으며 모든 페이지 에서도 쿠키에 접근할 수있다.
같이 읽기
