CORS

🚨 Access to XMLHttpRequest at 'https://api.test.com/auth/token' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

콘솔에서 위같은 빨간 에러메세지를 본 적이 다들 한 번쯤은 있을 것 같다. CORS?? CORS가 뭐길래, 뭐가 안된다고 뻘겋게 자기주장을 해대는 걸까?

cors란?

Cross

Origin

Resource

Sharing

교차 출처 리소스 공유라는 뜻이다.

그니까 그게 뭔디?

동일한 출처가 아닌 다른 출처에서 데이터를 주고받는 것을 허용하는 정책이다.

쉽게 말하자면 우리가 콘솔창에서 만난 CORS에러는 CORS 정책을 위반했다고 알려준 것이다.

그럼 출처는 뭘 뜻하는 걸까?

여기서 출처는 아주 쉽게 말하면 URL주소 이다.
그럼 URL이 토씨하나 안틀리고 똑같아야 동일 출처고, 한 글자라도 틀리면 다른 출처일까?

아니다. URL에서 프로토콜, 호스트, 포트번호가 같으면 동일 출처라고 한다.

https://www.test.com/users?page=1

위 URL을 구성요소별로 분리하면 아래처럼 된다.

https:// - Protocol

www.bubbletap.com - Host

/users - Path

?page=1 - Query String

출처 내의 포트 번호는 생략이 가능하다. 각 웹에서 사용하는 HTTP, HTTPS 프로토콜의 기본 포트 번호가 정해져있기 때문이다. 하지만 https://naver.com:123 처럼 포트 번호가 명시적으로 포함되어 있다면 포트 번호까지 일치해야 동일 출처로 인정된다.

자꾸 동일출처 동일출처 거리는데 그럼 동일 출처 관련 정책도 있을까?

SOP라고 있다.

SOP란?

Same

Origin

Policy

같은 출처에서만 리소스를 공유할 수 있다 라는 규칙을 가진 정책이다.

음? 그럼 다른 출처에서 데이터를 주고받는 것을 허용하는 정책인 CORS랑 부딪히지않나? 쟤는 허용한다는데... 얘는 같은데서만 공유하라그러고... 대체 누구 말을 들으라는건지...

같은 출처에서만 리소스 공유가 가능하다는 정책이긴 하지만, 웹이라는 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔해졌기 때문에 무작정 막을 수는 없으니 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 했다.

그 중 하나가 바로 CORS 정책을 지킨 리소스 요청이다.

다른 출처에서 데이터를 주고받는 것을 허용하는 정책인 CORS가 SOP 정책의 예외 정책이라고 볼 수 있다.

우리가 다른 출처로 리소스를 요청하면 SOP 정책을 위반한 것이고,
SOP 예외 조항인 CORS 정책마저 지키지 않으면 아예 다른 출처의 리소스를 사용할 수 없는 것이다.

이런 정책들을 까다롭고 귀찮기만한 거라고 생각하면 안된다.

다른 출처의 어플리케이션이 서로 통신하는 것에 대해 아무런 제약도 존재하지 않는다면
악의를 가진 누군가가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting)와 같은 방법을 사용하여 사용자의 정보를 탈취하기가 너무나도 쉬워진다.

CORS라는 방어막이 있기 때문에 우리가 여기저기서 가져오는 리소스가 안전하다는 최소한의 보장을 받을 수 있는 것이다.

CORS는 어떻게 동작할까?

기본적으로 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아보낸다.

이후 서버가 이 요청에 대한 응답 헤더의 Access-Control-Allow-Origin이라는 값에 허용된 출처값을 내려주고, 브라우저는 Origin과 서버가 내려준 Access-Control-Allow-Origin을 비교해 유효한 응답인지 아닌지 결정한다.

이건 기본적인 흐름이고, CORS가 동작하는 방식은 3가지 시나리오에 따라 변경된다.

1. Preflight Request

일반적으로 가장 자주 마추지는 시나리오로, 이름처럼 브라우저가 예비 요청과 본 요청으로 나누어서 서버로 전송하는 방식이다. 브라우저 스스로 이 요청이 안전한지 확인하는 것이다. 여기서 예비 요청을 Preflight라고 부르고, 예비 요청에는 HTTP 메소드 중 OPTION 메소드가 사용된다.

1. fetch 명령

2. 브라우저가 서버에게 예비 요청을 보냄

3. 서버가 허용 또는 금지 정보를 응답 헤더에 담아 브라우저에게 응답

4. 브라우저가 자신이 보낸 예비 요청과 서버가 응답해준 허용 정책을 비교해 안전하다고 판단되면 본 요청을 보냄

5. 서버가 본 요청에 대해 응답

6. 브라우저가 최종적으로 응답 데이터를 자바스크립트에게 넘겨줌

대부분의 경우 이렇게 예비 요청, 본 요청을 나누어 보내는 프리플라이트 방식을 사용하기는 하지만, 모든 상황에서 이렇게 두 번씩 요청을 보내는 것은 아니다. 어떤 경우에는 예비 요청없이 본 요청만으로 검사하기도 한다. 그 경우의 방식을 아래에서 살펴보도록 하자.

2. Simple Request

정식 명칭은 아니지만 MDN 문서에서 Simple Request라고 부르고 있다.

예비 요청을 보내지 않고 서버에게 본 요청만 보낸 뒤, 서버가 이에 대한 응답 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면, 그 때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.

1번 프리플라이트 방식과 예비 요청 유무만 다르다.

오? 그럼 예비요청 보내기 귀찮을텐데 항상 이렇게 하면 되는거 아닌가?

아무때나 가능한 건 아니고 특정 조건을 만족할 시에만 예비 요청 생략이 가능하다.
그 조건은 3가지인데, 모두 만족 시키기에는 쉽지 않다.

1. 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.

2. Accept, Accept-Language, Content-Language, Content-Type, 
DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.

3. 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, 
multipart/form-data, text/plain만 허용된다.

가능한가?

1. PUT이나 DELETE 같은 메소드를 사용하지 않으면 가능하다.

2. 명시된 헤더들은 정말 기본적인 헤더들이기 때문에 복잡한 상용 웹 어플리케이션에서 이 헤더들 외에 
추가적인 헤더를 사용하지 않는 경우는 매우 적다. Authorization 헤더 조차 사용하면 안된다.

3. 대부분의 HTTP API는 text/xml이나 application/json 컨텐츠 타입을
가지도록 설계되기 때문에 사실상 이 조건을 만족시키는 상황을 만들기는 쉽지 않다.

위처럼 조건이 많이 까다롭기 때문에 잘 쓰지 않는다.

3. Credentialed Request

요청 헤더에 인증 정보를 담아 보내는 방식으로, CORS의 기본적인 방식보다 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용한다. 이 경우에는 프론트, 서버 양측 모두 CORS 설정이 필요하다.

프론트 측에서는 요청 헤더에 withCredentials : true 를, 서버 측에서는 응답 헤더에 Access-Control-Allow-Credentials : true 를 넣어줘야 한다.

요청에 인증과 관련된 정보를 담을 수 있게 해주는 credentials 옵션 값으로 검사 조건을 추가할 수 있다.

same-origin (기본값) - 같은 출처 간 요청에만 인증 정보를 담을 수 있다

include - 모든 요청에 인증 정보를 담을 수 있다

omit - 모든 요청에 인증 정보를 담지 않는다

Access-Control-Allow-Origin 값으로 모든 출처를 허용한다는 의미인 *를 설정했다면 다른 출처에서 리소스를 요청할 때 CORS 정책 위반으로 인한 제약을 받지 않는다.
그래서 http://localhost:8000과 같은 로컬의 개발 환경에서도 fetch API를 사용하여 마음대로 리소스를 요청하거나 받아올 수 있다.

하지만 credentials 옵션을 모든 요청에 인증 정보를 포함하겠다는 의미를 가진 include로 적용한다면, 서버 측에서 Access-Control-Allow-Origin 을 설정할 때, *로 설정하면 에러가 발생한다. 인증 정보를 다루는 만큼 출처를 정확하게 설정해주어야하기 때문이다.

브라우저 인증 모드가 include일 경우, Access-Control-Allow-Origin에는 *를 사용할 수 없고, 명시적인 URL이어야한다.

CORS를 해결하는 방법

Access-Control-Allow-Origin 설정하기

*를 사용하면 편하기야 하겠지만 어디서 오는 지도 모르는 요청까지 다 허용하기 때문에 보안 이슈가 발생할 수 있다. 귀찮더라도 출처를 명시하는 것이 좋다.

Webpack Dev Server로 리버스 프록싱 하기.

프론트쪽 로컬에서 CORS 정책을 우회하는 방법이라고 볼 수 있다.

module.exports = {
devServer: {
    proxy: {
    '/api': {
        target: 'https://api.example.com',
        changeOrigin: true,
        pathRewrite: { '^/api': '' },
    },
    }
}
}

이 코드를 풀이하면, 뒤에서 웹팩이 https://api.example.com으로 요청을 프록싱해서 마치 CORS 정책을 지킨 것처럼 브라우저를 속이는 것이다. 즉, 프록싱을 통해 CORS 정책을 우회하는 것이다.

물론 주의해야한다. 프로젝트를 배포하는 경우, 리액트로 만든 서비스와 api가 동일한 도메인에서 제공 되는 경우에는 이대로 계속 진행하면 되지만, 만약에 api의 도메인과 서비스의 도메인이 다르다면 글로벌 baseURL을 따로 설정해주어야 한다.

API 서버의 출처는 https://api.example.com이고 클라이언트 어플리케이션을 서빙하는 서버의 출처는 https://www.example.com이라면

fetch('/api/test');를 했을 때 아래와 같은 이슈가 발생할 수 있다.

로컬환경에서는
GET https://api.example.com/test 200 OK

실제 서버
GET https://www.example.com/api/test 404 Not Found

이 이슈를 해결하기 위해 process.env.NODE_ENV와 같은 빌드 환경 변수를 사용하여 분기 로직을 작성하는 방법이 있다.

프로젝트를 개발 할 때 proxy 를 필수적으로 사용하는 것은 아니지만, 만약 사용하면 백엔드 쪽에서 개발서버를 위한 CORS 설정으로 불필요한 코드 작성을 방지할 수 있으니 꽤나 유용한 기능이라고 볼 수 있다.

하지만 운영 환경보다 로컬 개발 환경에서 쓰기에 용이하고, 근본적인 문제 해결 방법은 아니기 때문에 결국 운영 환경에서 CORS 정책 위반 문제를 프론트에서만 해결하기엔 어려움이 있다.

그렇기 때문에 CORS는 백엔드와 프론트 어느 한 쪽만 신경써야될 게 아니라, 모두 CORS에 대해 잘 알고 있는 것이 중요하다고 생각한다.