프론트엔드 개발을 하다보면 한 번쯤은 경험하는 cors! 개발 과정에서 CORS 에러를 해결하기 위해 proxy를 사용했습니다. CORS에 관한 자료는 CORS는 왜 이렇게 우리를 힘들게 하는걸까? 해당 글의 도움을 많이 받았습니다.

요약

CORS는 다른 출처임에도 브라우저상에서 서로 상호작용이 가능하도록 하는 정책입니다. 배포된 환경에서 (정석적으로) 이를 사용하기 위해서는 BE서버에서 HTTP 응답 헤더의 Access-Control-Allow-Origin 속성에 FE 서버(브라우저에서 호스팅되는 서버)의 URL을 추가해주면 됩니다.

요청에 인증 정보(쿠키, 권한 부여 헤더 또는 TLS 클라이언트 인증서 등등)가 담겨있는 상태에서 다른 출처의 리소스를 요청하고 싶다면 아래 3가지 설정을 해야합니다.

  1. 요청 헤더에 withCredentials: true를 설정하기
  2. Access-Control-Allow-Origin에 와일드카드(*)를 사용할 수 없고, 명시적인 URL을 사용하기
  3. 서버 측 응답헤더에 Access-Control-Allow-Credentails: true 설정하기

개발환경에서 BE와 협의 없이 간단하게 해결하기 위해서는 local환경에서 proxy 서버를 사용하면 됩니다. (BE 서버 http 응답헤더에 Access-Control-Allow-Origin속성에 와일드 카드나 localhost를 직접 사용하는 건 지양해야합니다.) proxy서버를 사용하면 proxy서버가 BE서버의 origin과 동일한 origin에서 상호작용함으로써 CORS정책 관련 이슈를 우회할 수 있습니다. CORS는 브라우저의 정책이기 때문입니다!

현재 저희는 react를 사용하고 있는데 개발환경에서 간단하게 해결할 수 있는 방법으로는 cra의 package.json, webpack dev server 그리고 http-proxy-middleware가 있습니다.

// 프록시 쓰지 않았을때
// localhost:8080(클라이언트 측) --X (CORS)--> domain.com (서버 측)

// 프록시를 설정 후
// localhost:8080(클라이언트 측) < -- O -- > 프록시가 설정된 local server < --- > domain.com (서버 측)

1. SOP (Same Origin Policy)

SOP는 다른 출처의 리소스를 사용하는 것에 제한하는 보안 방식입니다. origin(출처)은 url의 구성요소 중 protocol, domain, port로 이뤄져있습니다.

브라우저는 protocal, domain, port 중 어느 하나라도 다르면 다른 origin이라고 판단한다.

http://localhost 와 동일한 origin은 무엇일까? (80은 생략되어 있다.)