[FE - ConnecTo] DAY51 TIL👩🏻‍💻

22.09.22 수업 시간 중 스스로 공부한 내용들을 정리하였습니다 😊
피드백은 언제나 환영입니다! 🍊

CORS 개념

• Cross Origin Resource Sharing
  • 교차 출처 정보 공유에 관한 정책
• 보안 상의 이유로 모든 웹사이트는 기본적으로 SOP(Same-Origin Policy)를 따른다. 다시 말해, 같은 출처에 대한 데이터 요청은 항상 허락되지만, 다른 출처로 데이터를 요청할 경우 특별한 규칙에 따라 허락을 받아야 한다.
• 해당 규칙이 CORS로, 다른 출처에 데이터를 요청할 때 CORS를 지키지 않으면 서버가 정상적으로 응답하더라도 브라우저가 응답을 파기하고 클라이언트에 에러를 던진다.

출처

• CORS에서 이야기하는 출처는 URI를 구성하는 요소 중 Scheme, Host, Port를 말한다.
• 3가지 중 하나라도 다른 경우 다른 출처로 간주하며, 포트 번호의 경우 따로 명시되지 않은 경우 HTTP/HTTPS의 기본 포트번호를 기준으로 한다.
• 출처의 구성 요소
  • Scheme
    • http:// , https://와 같은 프로토콜. http와 https는 다른 프로토콜이기 때문에, 호스트가 같더라도 서로 다른 출처로 인식하여 CORS에러가 발생할 수 있다.
  • Host
    • www.naver.com과 같이, 다른 웹사이트와 구분되는 독립적인 이름. 우리가 흔히 주소라고 부르는 부분을 말하며, 뒷부분의 파라미터와 쿼리스트링 등은 포함하지 않는다.
  • Port
    • 생략되는 경우가 많으며, 명시할 경우 호스트 뒤에 붙는다.
      • 예: https://www.pereng.com:8000
    • http의 기본 포트번호는 :80, https의 기본 포트번호는 :443 이다.

누가 확인하지?

• CORS는 브라우저에서 판단하고 적용한다. 클라이언트와 서버는 자신이 누구인지, 어떤 요청을 허락할 것인지를 요청 헤더에 담아 전송하고, CORS위반 여부는 브라우저가 판단한다.
  • 따라서 CORS를 위반한 경우 서버에서는 정상적으로 처리했더라도 브라우저에서 응답을 파기한다.
    • 서버 로그에는 정상적인 통신으로 기록된다는 의미
  • 브라우저마다 판단 기준이 조금씩 다를 수 있으며, 특히 IE의 경우 출처 판단 시 포트 번호를 무시한다.

CORS 관점에서 보는 3가지 통신 방법

1. Preflight
   1. 브라우저가 서버에 예비 요청을 보낸다
   2. 예비 요청에 대해, 서버는 어떤 것들이 허용되고 금지되는지에 대한 정보를 응답 헤더에 담아 보낸다.
      1. origin, credential, method 등
   3. 브라우저는 예비 요청과 그에 대한 서버의 응답을 비교하여 안전하다고 판단될 경우 본 요청을 서버로 보낸다
   4. 이후 서버가 응답하면 브라우저는 응답 데이터를 클라이언트에 넘겨준다
2. Simple Request
   1. 브라우저는 예비 요청 없이 서버에 바로 본 요청을 보내고, 응답 헤더의 내용을 바탕으로 CORS 정책 위반 여부를 파악하여 처리한다
      1. 예비 요청이 없다는 점을 제외하고, 1번과 로직이 같다
      2. 제약 조건이 까다로워, 실제로 사용되는 일이 드물다
         1. 사용 가능한 method 제한,
         2. 사용 가능한 header 제한,
         3. 사용 가능한 Content-type 제한
3. Credentialed Request
   1. 요청 헤더에 Credentials를 추가하여 요청을 보낼 때 쿠키와 같은 인증 정보를 함께 전송
      1. Same-origin: 같은 출처에 보낼 때만 인증 정보 전송
      2. Include: 모든 요청에 대해 인증 정보 전송
      3. Omit: 모든 요청에 인증 정보를 담지 않음
   2. 인증 정보가 담긴 상태에서 다른 출처로 리소스를 요청할 경우 기존 CORS 룰에 새로운 규칙을 2개 추가함
      1. 서버측에서 Access-Control-Allow-Credentials: true를 꼭 사용해야 함
      2. 서버측에서 Access-Control-Allow-Origin 에 명확한 출처를 명시해야 함
         1. 보안 상의 이슈로 * 를 사용할 수 없음

CORS 이슈를 해결하는 방법

서버

• Access-Control-Allow-Origin 설정하기
  • 가급적 * 보다는 구체적인 출처를 명시할 것(보안 이슈)
  • 클라이언트에서 요청에 Credentials: include옵션을 사용한 경우, * 를 사용하면 CORS 에러 발생
• Access-Control-Allow-Credentials: true 확인하기
  • 클라이언트에서 Credentials: include옵션을 사용한 경우, 그에 대해 해당 옵션을 사용하지 않으면 CORS 에러가 발생함.

클라이언트

• Proxy 설정하기

  • Proxy란?

    • 요청을 Proxy에서 설정한 주소로 우회하여 전송하는 방법
    • http-proxy-middleware 라이브러리 사용

  • 예시

    //  `/api`로 시작하는 요청의 주소를 원래 클라이언트 주소가 아닌 target에서 설정한 주소로 우회해준다.
    
    // 따라서 target의 주소와 요청을 받을 서버의 주소를 일치시키면, 동일한 출처로 판단하여 CORS 정책 위반을 피해갈 수 있다
    
    proxy: {
          '/api': {
            target: 'https://api.evan.com',
            changeOrigin: true,
            pathRewrite: { '^/api': '' },
          },
        }
    

  • 주의사항

    • 개발 단계에서만 적용되므로, 실제 프로덕션 환경에서는 프록시 처리가 되지 않는다
      • 빌드 이후에는 적용되지 않기 때문

참고자료

https://evan-moon.github.io/2020/05/21/about-cors/#cors를-해결할-수-있는-방법

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://phase-dryosaurus-8ac.notion.site/CORS-9f5a68d44a8f4b46bbb647a9b50c2638