그러나 상위도메인으로만 변경이 가능하기 때문에 company.com을 다른 도메인으로 변경하는것은 불가능하다.
교차 출처 네트워크 접근
동일 출처 정책은 서로 다른 출처 사이에서 XMLHttpRequest 혹은 img 요소를 사용할 때 등의 상호작용을 통제한다. 상호작용은 보통 다음 세 가지 범주로 나뉜다.
교차 출처 쓰기는 보통 허용한다. (링크, 리다이렉트, 양식 제출) 일부 HTTP 요청을 프리플라이트를 요구함.
교차 출처 삽입은 보통 허용함.
로 추가하는 js. 그러나 구문오류는 동일 출처 스크립트에서만 확인가능함.
로 적용하는 css.
img, video, audeo, object, embed등 외부리소스
교차 출처 읽기는 보통 불허하지만, 종종 교차 출처 삽입 과정에서 읽기 권한이 누출된다.
프리플라이트
프리플라이트 요청방식은 요청을 한번에 보내지 않고 예비 요청과 본 요청으로 나누어서 서버로 전송한다. 이때 예비요청을 프리플라이트라고 부른다.
이 예비요청에는 HTTP 메소드 중 OPTIONS 메소드가 발생한다.
js fetch API를 사용하여 브라우저에게 리소스를 받아오라는 명령을 내리면 브라우저는 서버에게 예비요청을 먼저 보내고, 서버는 이 예비 요청에 대한 응답으로 현재 자신이 어떤 것들을 허용하고, 어떤 것들을 금지하고 있는지에 대한 정보를 응답 헤더에 담아서 브라우저에게 다시 보내준다.
이후 브라우저는 자신이 보낸 예비 요청과 서버가 응답에 담아준 허용 정책을 비교한 후, 이 요청을 보내는 것이 안전하다고 판단되면 같은 엔드포인트로 다시 본 요청을 보낸다.
예비 요청의 응답헤더에 Access-Control-Allow-Origin 값으로 출처 위반 여부를 파악한다.
CORS(Cross-Origin Resource Sharing)
교차 출처 리소스 공유 정책
웹이라는 오픈 스페이스 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이라 무작정 막을수도 없는 노릇이니 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청을 출처가 다르더라도 허용하기로 했는데, 그 중 하나가 "CORS 정책을 지킨 리소스 요청"이다.
CORS 정책을 지킨것이란? - 다른출처의 리소스를 요청할 때 HTTP 프로토콜의 요청 헤더에 Origin 이라는 필드에 요청을 보내는 출처를 함께 담아 보낸다. 이후 서버가 요청에 대한 응답을 할 때 Access-Control-Allow-Origin 이라는 값에 "이 리소스를 접근하는 것이 허용된 출처"를 내려주고, 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-A-O를 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.
위의 프리플라이트도 CORS를 검증하는 시나리오 중 하나이다. 가장 일반적임.
다른 시나리오는 사전요청없이 바로 검증하는방법, 보안을 좀 더 강화시킨 Credential Request가 있다.
CORS를 해결하는 방법
서버에서 Access-Control-Allow-Origin 세팅하기
프록시 사용하기.
클라이언트에서 프록시서버에 요청을 보내고, 프록시서버는 원래 요청할 서버에다 클라이언트의 요청을 보낸 후, 서버에서 온 응답의 헤더에 Access-Control-Allow-Origin을 허용되는 값으로 담아서 다시 클라이언트에 돌려줌
