원래 SOP(Same Origin Policy)로 시작하였다.

SOP는 동일 출처 정책이라고 번역된다. 동일한 출처끼리 상호작용만 허용하는 정책을 의미한다. 같은 출처끼리 리소를 주고 받아야 했다.

출처(Origin)란?

출처

출처(Origin) = protocal + host + port

프로토콜, 호스트, 포트 모두 동일해야 동일한 출처라고 할 수 있다.

https://www.example.com:443 을 기준으로 같은 출처인지 알아보자 

1. https://test.example.com:443 -> 호스트가 달라서 다른 출처이다. 
2. http://www.example.com:80 -> 프로토콜과 포트가 달라서 다른 출처이다. 
3. https://www.example.com:8080 -> 포트가 달라서 다른 출처이다.  

SOP의 필요성

SOP는 웹 보안을 위한 기본 워칙이다. 만약 SOP가 지켜지지 않는다면, 웹 생태계 전체에 보안 위협이 될 수 있다. 악의적인 의도를 가진 출처(서버)에 접근해 리소스를 가져온다면, 해당 리소스를 통해서 브라우저 내 개인 정보(쿠키, 세션, 토큰)을 임의로 조작하거나 탈취할 위험이 있다. 악성 출처에 감여된 브라우저가 다른 출처에 접근하는 과정에서 의도하지 않은 피해가 발생할 우려도 있다. 이를 때문에 그 동안 SOP를 고수해온 것 이다.

CORS(Cross-Origin Resource Sharing) 등장

웹 생태계가 풍부해지면서 다른 출처로 리소스를 요청할 사항이 늘어나기 시작한다. 당장 아무 회사 소개 페이지에 들어가봐도 외부 api를 활용해서 지도 위에 회사 위치를 표기하고 있다. 이 경우도 다른 출처 리소스를 요구하는 작업이다.

CORS 동작원리

CORS은 simple requests(단순 요청), preflighted request(프리플라이트 요청) 두 종류로 나눌 수 있다.

simple requests (단순 요청)

단순 요청은 한 번 요청과 응답으로 구성되어 있다.

[https://www.exampl](https://foo.example)e.com 에서 다른 출처에 리소스를 요청한다고 가정해보자

1. 요청 헤더에 Origin: [https://www.exampl](https://foo.example)e.com 추가
2. 응답 헤더에 Access-Control-Allow-Origin: * 혹은 Access-Control-Allow-Origin: [https://www.exampl](https://foo.example)e.com
3. 브라우저에서 Origin이 Access-Control-Allow-Origin 에 포함되어 있는지 확인 후에 리소스를 처리한다. 만약 Access-Control-Allow-Origin 에 origin이 없다면 cors 이슈가 발생한다.

preflighted requests (프리플라이트)

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

1. 프리플라이트는 단순 요청과 달리 option메소드를 통해서 미리 요청을 보내는 과정이 존재한다. 이 과정을 통해 실제 요청이 안전한지 검증한다. 프리플라이트 요청 헤더에 실제 요청에서 보낼 메소드 종류를 나타내는 Access-Control-Reqeust-Method 와 실제 요청에서 보낼 헤더 종류를 나타내는 Access-Control-Request-Headers 도 같이 보낸다.

2. 정상적으로 응답이 오면 앞선 단순 요청과 마찬가지로 실제 요청을 보낸다.

그외 보안..

인증 정보가 담긴 요청에 경우 응답에 [Access-Control-Allow-Credentials](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials) : true 헤더가 있어야 한다. 만약 없다면 응답을 무시한다…