CORS란? - Githubissues

CORS(Cross-Origin Resource Sharing) : 다른 출처로의 리소스 요청을 제한하는 것과 관련된 정책

SOP(Same-Origin Policy) : 동일한 출처에서만 리소스를 공유할 수 있다

동일 출처 정책이 필요한 이유 : 출처가 다른 두 어플리케이션이 자유로이 소통할 수 있도록 제약이 없다면, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다.
같은 출처(origin) & 다른 출처의 기준 : URL의 구성 요소 중 Scheme, Host, Port 이 3가지가 동일한가 ex)https://test.github.io:80
- Scheme : https://
- Host : test.github.io
- Port : 80
브라우저별로 출처를 비교하는 로직이 구현되어 있음

클라이언트 : 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아보낸다.
서버 : 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin이라는 값에 “이 리소스를 접근하는 것이 허용된 출처”를 내려준다
브라우저 : 응답을 받으면 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.

예비요청(Prefilght) : 요청을 보낼때 한번에 바로 보내지않고, 먼저 예비 요청을 보내 서버와 잘 통신되는지 확인한 후 본 요청 보냄
단순요청(Simple Request) : 예비 요청(Prefilght)을 생략, 바로 서버에 본 요청을 보낸 후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin 헤더를 보내주면 브라우저가 CORS정책 위반 여부를 검사하는 방식
인증된 요청 (Credentialed Request) : 라이언트에서 서버에게 자격 인증 정보(Credential)를 실어 요청할때 사용되는 요청 (자격 인증 정보: 세션 ID가 저장되어있는 쿠키(Cookie) 혹은 Authorization 헤더에 설정하는 토큰 값)

서버 : Access-Control-Allow-Origin 세팅하기
- 소스 코드 내에서 응답 미들웨어 등을 사용하여 세팅하는 것을 추천 (cf. Spring, Express, Django와 같이 이름있는 백엔드 프레임워크의 경우에는 모두 CORS 관련 설정을 위한 세팅이나 미들웨어 라이브러리를 제공)
프론트엔드 : Webpack Dev Server로 리버스 프록싱하기 프론트엔드 개발자는 대부분 웹팩과 webpack-dev-server를 사용하여 자신의 머신에 개발 환경을 구축하게 되는데, 이 라이브러리가 제공하는 프록시 기능을 사용하면 아주 편하게 CORS 정책을 우회할 수 있다.
```
module.exports = {
devServer: {
  proxy: {
    '/api': {
      target: 'https://api.test.com',
      changeOrigin: true,
      pathRewrite: { '^/api': '' },
    },
  }
}
}
```
이렇게 설정을 해놓으면 로컬 환경에서/api로 시작하는 URL로 보내는 요청에 대해 브라우저는 localhost:8000/api로 요청을 보낸 것으로 알고 있지만, 사실 뒤에서 웹팩이 https://api.test.com으로 요청을 프록싱해주기 때문에 마치 CORS 정책을 지킨 것처럼 브라우저를 속이면서도 우리는 원하는 서버와 자유롭게 통신을 할 수 있다. 즉, 프록싱을 통해 CORS 정책을 우회할 수 있는 것이다.
- 실제 프로덕션 환경에서도 클라이언트 어플리케이션의 소스를 서빙하는 출처와 API 서버의 출처가 같은 경우에 사용

jinsusong / CS-Study