브라우저 HTTP 요청 정책
우리는 개발하면서 수많은 cors 관련 에러 메시지를 봤던 경험이 있을것 이다.
이러한 현상이 일어나는 이유는
브라우저에서 보안적인 이유로 cross-origin HTTP 요청들을 제한하고
SOP(Same Origin Policy) 정책을 따르고 있기 때문이다.
만약 cross-origin 요청을 하려면 서버의 동의가 필요하다.
서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절한다.
HTTP 요청에 따른 정책
img, video, script, link 태그 → 기본적으로 Cross-Origin 정책을 지원함
- link 태그의 href 에서 다른 사이트의 .css 리소스에 접근하는 것이 가능
- img 태그의 src 에서 다른 사이트의 .png, .jpg 등의 리소스에 접근하는 것이 가능
- script 태그의 src 에서 다른 사이트의 .js 리소스에 접근하는 것이 가능 (type="module" 속성은 제외)
XMLHttpRequest, Fetch API → 기본적으로 Same-Origin 정책을 따름
- 다른 도메인에게 ajax 요청 API 호출시
- 웹 폰트 CSS 파일 내 @font-face에서 다른 도메인의 폰트 사용 시
- 자바스크립트에서의 요청은 기본적으로 서로 다른 도메인에 대한 요청을 보안상 제한한다.
- 브라우저는 기본으로 하나의 서버 연결만 허용되도록 설정되어 있기 때문이다. (주로 자신의 서버)
Origin(출처)란?
프로토콜 + 도메인 + 포트 로 이루어진 URL을 뜻하면
3가지 중 하나라도 다르면 다른 출처이다
SOP(Same-Origin Policy) - 동일 출처 정책
SOP(Same Origin Policy) 정책은 단어 그대로 동일한 출처에 대한 정책을 말한다.
그리고 이 SOP 정책은 '동일한 출처에서만 리소스를 공유할 수 있다.'라는 법률을 가지고 있다.
즉, 동일 출처(Same-Origin) 서버에 있는 리소스는 자유로이 가져올수 있지만,
다른 출처(Cross-Origin) 서버에 있는 이미지나 유튜브 영상 같은 리소스는 상호작용이 불가능하다는 말이다.
동일 출처 정책이 필요한 이유
사실 출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경은 꽤 위험한 환경이다.
공격자가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서
우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다.
CORS(Cross-Origin Resource Sharing) - 교차 출처 리소스 공유
교차 출처 리소스 공유(Cross-Origin Resource Sharing)는 단어 그대로 다른 출처의 리소스 공유에 대한 허용/비허용 정책이다.
아무리 보안이 중요하지만, 개발을 하다 보면 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야 하는 케이스도 있으며, 또한 실무적으로 다른 회사의 서버 API를 이용해야 하는 상황도 존재한다.
따라서 이와 같은 예외 사항을 두기 위해 CORS 정책을 허용하는 리소스에 한해 다른 출처라도 받아들인다는 것이다.
브라우저의 CORS 기본 동작
-
클라이언트에서 HTTP 요청시 헤더에 "Origin" 필드에 "출처"를 담아 보냄
-
서버는 응답헤더에 Access-Control-Allow-Origin필드에 "출처" 클라이언트로 전달한다.
->
1) 이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더에 Access-Control-Allow-Origin이라는
필드를 추가하고 값으로 '이 리소스를 접근하는 것이 허용된 출처'를 내려보낸다. -
클라이언트에서 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.
->
1) 이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의
Access-Control-Allow-Origin을 비교해본 후 차단할지 말지를 결정한다.
2) 만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. (CORS 에러)
3) 위의 경우에는 둘다 http://localhost:3000이기 때문에 유효하니 다른 출처의 리소스를 문제없이 가져오게 된다.
결론
결론은 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서
클라이언트에 응답하면 되는 것이었다. 즉, 백엔드 개발자가 고쳐야될 부분인 것이다.
즉 클라이언트 Origin 출저와 서버의 Access-Control-Allow-Origin 출저가 동일하면 cors 허용됨
