SOP(Same origin policy), CORS(Cross origin resource sharing)

예전에 MVC 방식이 아닌, 프론트-백엔드로 구조가 분리된 서비스를 개발하면서 겪었던 에러였는데 다시 한번 정리 해본다.

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

95년 브라우저에 자바스크립트가 도입된 넷스케이프 브라우저 2.0 이후 2.02버전부터 SOP라는 보안정책이 만들어졌다.
접속한 곳의 출처(사이트) 가 아닌 다른 출처의 리소스와 상호작용하는 것을 차단해서 보안적인 위험으로부터 막는 방식이다.
이 방식이 없다면 실수로 접속한 피싱 페이지의 악성 스크립트가 해당 브라우저에 은행 사이트에 접속시 아이디와 비밀번호를 나한테 보내라고 하는 req에 대해서 res를 보낼 수 있다. 

- SOP (Same Origin Policy): 브라우저에서 다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식. 

이러한 SOP 정책에 대한 예외처리를 CORS로 이용하면 할 수 있다. cross-origin HTTP요청은 다른 도메인 혹은 하위도메인, 다른 포트, 다른 프로토콜(http, https)에 대한 요청일 것이다. 

- CORS(cross-origin resource sharing): 브라우저에서 실행 중인 스크립트에서 시작되는 cross-origin HTTP 요청을 제한하는 브라우저 보안 기능. REST API의 리소스가 비 단순 cross-origin HTTP 요청을 받을 경우 CORS 지원을 활성화해야됨.

정리:
CORS정책에 따라 정상적으로 타 출처 리소스를 받으려면, 리소스를 가져올 서버에 직접 접근해서 서버측에 응답시 Access-Control-Allow-Origin 헤더를 추가하도록 해야한다. 서버엔진 설정을 만져도 되지만, 아무래도 백엔드 소스코드를 건드리는 것이 좋다. 백엔드 프레임워크들은 모두 CORS 관련 설정을 내장했거나 라이브러리를 통해서 지원을 받을 수 있다. 

실서비스 배포를 하는 것이라면 당연히 서버측에서 설정처리를 해줘야하지만, 프론트 개발시 로컬 개발환경에서 요청을 하고 싶을 때는 웹팩에서 제공하는 프록시를 이용하면 편리하게 우회요청을 할 수 있다.

심화:
CORS가 동작하는 방식에는 3가지 방식이 있는데 예비요청과 본요청 2번을 보내면서 cors가 허용된 주소를 한번 확인하고 본요청을 보내는 방식이 있고(preflight), 허용되든 말든 일단 보내보는 단순요청 방식이 있고, 인증관련 요청을 담아서 보내는 방식이 있다. (credentialed request)

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

교차 출처 리소스 공유 (CORS) - HTTP | MDN

https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/how-to-cors.html

REST API 리소스에 대한 CORS 활성화 - Amazon API Gateway