[네트워크] CORS 총정리

 

 

 

웹 개발을 처음 시작하다보면 CORS 에러를 반드시 만나게 됩니다.

CORS 처음 접하는 경우 굉장히 많은 고생을 하게 되는데요 (저도 그랬고..😭),

이번 글을 통해 CORS에 대해 완전히 정리하고 넘어갈 수 있었으면 좋겠습니다.

 

CORS(Cross Origin Resource Sharing)에 대해 알아보기 위해 우선 O에 해당하는 Origin이 무엇인지부터 알아보도록 하겠습니다.

 

 

 

 

 

 

🧐 Origin

URL에서 프로토콜(Protocol), 호스트(Host), 포트(Port)를 합친 것이 Origin입니다.

 

 

 

 

 

 

 

 

 

🧐 다른 Origin의 리소스를 사용할 때의 보안 문제

(예시를 위한 가정입니다.)

저는 현재 깃허브에 가입하여 사용하고 있는데요, 로그인 시 깃허브로부터 인증과 관련된 쿠키를 받아오게 됩니다.

 

 

 

 

이때 해커가 제 메일로 어떠한 링크를 하나 보냈다고 가정하겠습니다.

해당 링크는 클릭하지 않고서는 도저히 참을 수 없을 정도로 흥미로운 링크입니다.

 

 

 

 

저는 해당 링크를 누를 것이고, 해커가 만든 주소로 이동을 하게 됩니다.

이때 해당 주소의 html 혹은 js 파일에, 깃허브의 모든 레포지토리를 삭제하는 코드가 들어있었다고 가정하겠습니다.

 

 

그렇게 되면 링크 클릭 -> 해커의 사이트 접속 -> 코드 실행 -> 깃허브 레포지토리 삭제 의 상황이 발생하게 됩니다.

 

 

이러한 문제(CSRF 또는 XSS 공격 문제)를 방지하기 위해 SOP(Same Origin Policy)가 등장하였습니다.

 

 

 

 

 

 

 

 

 

 

 

 

🧐 SOP(Same Origin Policy)

Same Origin Policy는 이름 그대로 같은 Origin의 요청에 대해서만 허가하는 정책입니다.

 

 

이를 통해 위에서 발생하는 문제를 해결할 수 있는데요,

깃허브 입장에서는 http://hac.ker 의 요청이 https://github.com과 다른 Origin이기 때문에 해당 요청을 거부합니다.

예전에야 프론트엔드와 백엔드를 별도로 구성하지 않았으므로 다른 Origin으로 요청을 보낼 필요가 없었지만, 시대가 지남에 따라 웹 환경에서는 다른 Origin의 리소스를 요청하고 사용하는 일이 굉장히 흔하게 발생하였습니다.

 

그렇다 보니 무작정 다른 Origin의 요청을 막는 대신 몇 가지 예외적인 경우를 두어 다른 Origin간의 리소스 요청을 허용하도록 하였는데요, 이 중 하나가 CORS 입니다.

 

 

 

 

 

 

 

 

 

 

 

🧐 CORS (Cross Origin Resource Sharing)

CORS는 추가적인 HTTP 헤더를 사용하여 다른 출처(Cross Origin)간의 리소스를 공유할 수 있도록 해주는 체제입니다.

 

교차 출처간 리소스 공유는 기본적인 경우에는 SOP에 의해 방지되어 있으나, 다음과 같은 경우 CORS 요청을 허용합니다.

• XMLHttpRequest와 Fetch API 호출 시
• 웹 폰트(@font-face)에서 교차 도메인 폰트 사용 시
• ...

 

이때 알아야 할 점이, 출처를 비교하는 로직은 서버에 구현된 것이 아니라 브라우저에 구현되어 있다는 것입니다.

즉 CORS에 위반되는 요청을 하더라도, 요청을 받는 서버가 같은 출처에서 보낸 요청만 받도록 로직을 구현한 경우가 아니라면 서버는 정상적으로 응답을 합니다.

이후 브라우저에서 이 응답을 분석한 뒤 CORS 위반이라고 판단되면 그 응답을 사용하지 않고 버리는 것입니다.

 

즉 CORS는 브라우저의 구현 스펙에 포함되는 정책이기 때문에, 브라우저를 통하지 않고 서버 간에 통신을 하거나 Postman 등을 사용하는 경우에는 해당 정책이 적용되지 않는 것입니다.

또한 CORS 정책을 위반하는 리소스 요청 때문에 에러가 발생했다고 해도 서버 쪽 로그에는 정상적으로 응답을 했다는 로그만 남기 때문에 CORS의 동작 방식을 모르면 굉장히 헤맬 수 있습니다.

 

 

CORS의 동작 원리를 자세히 살펴보기 전에 CORS에서 사용되는 HTTP 헤더에 간단히 살펴보고 넘어가겠습니다.

 

 

 

 

 

 

📕 CORS 관련 HTTP 헤더

🌱 요청 헤더

• Origin : 요청의 출처를 의미합니다.
• Access-Control-Request-Method : 요청을 보낼 메서드입니다.
• Access-Control-Request-Headers : 요청을 보낼 때 포함될 헤더들입니다.

 

 

🌱 응답 헤더

• Access-Control-Allow-Origin : 서버에서 리소스 요청을 허락할 Origin들입니다.
• Access-Control-Allow-Methods : 서버에서 리소스 요청을 허락할 HTTP Method들 입니다.
• Access-Control-Allow-Headers : 서버에서 리소스 요청을 허락할 HTTP Header들 입니다.
• Access-Control-Max-Age : Preflight 응답을 캐시하는 시간입니다.
• Access-Control-Allow-Credentials : credentials 모드가 include인 요청을 허용하기 위해 설정합니다.
• Access-Control-Expose-Headers : 기본적으로는 CORS 허용 목록 응답 헤더만 노출되지만, 클라이언트가 다른 헤더에 액세스할 수 있도록 할 때 사용합니다.

 

이들에 대해서는 맨 마지막에서 자세히 알아보도록 하겠습니다.

 

 

 

 

브라우저는 아래와 같이 요청 헤더와 응답 헤더를 비교하는데요,

요청	응답
Origin	Access-Control-Allow-Origin
Access-Control-Request-Method	Access-Control-Allow-Methods
Access-Control-Request-Headers	Access-Control-Allow-Headers

이때 CORS 정책을 위반했다고 판단하면 즉시 서버로부터 받은 응답을 버리고 예외를 발생시키기 때문에, 서버에서는 정상 응답이, 클라이언트에서는 CORS 예외가 발생하는 것입니다.

 

 

 

추가적으로 credentials 모드가 include인 요청(쿠키, 인증 관련 헤더들 등의 사용자 식별 정보가 담긴 요청)에 대해서는 보다 엄격합니다.

우선 요청을 보내는 측에서는 credentials 항목을 true로 세팅해야 하고,

받는 쪽에서는 Access-Control-Allow-Origin를 아무 출처나 허용한다는 와일드카드("*")가 아니라 보내는 쪽의 Origin을 정확히 명시한 뒤 Access-Control-Allow-Credentials 항목을 true로 맞춰주어야 합니다.

 

이는 아래의 Credentialed Request에서 자세히 살펴보겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 CORS 접근 제어 시나리오

CORS 접근 제어 시나리오에는 3가지 상황이 있습니다.

이들은 각각 Simple Request(단순 요청), Preflight Request(프리플라이트 요청), Credentialed Request(인증정보를 포함한 요청)이며, 하나하나 살펴보도록 하겠습니다.

 

 

 

 

 

 

 

 

🧐 Simple Request

다음에 살펴볼 Preflight와는 달리, 본 요청을 바로 보내면서 그 즉시 Cross Origin인지 확인하는 요청입니다.

다음과 같은 조건을 모두 충족하는 요청은 Simple Request를 통해 요청하게 됩니다.

 

📕 조건 1

HTTP Method는 다음 종류 중 하나여야 합니다.

• GET
• POST
• HEAD

 

 

📙 조건 2

Content Type은 다음 종류 중 하나여야 합니다.

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

 

 

 

📒 조건 3

HTTP Header는 다음 종류만 허용합니다.

• Accept
• Accept-Language
• Content-Language
• Content-Type

 

Simple Request의 2번 조건을 보면 application/json이 허용되지 않으며, 3번 조건을 보면 인증에 사용되는 Authorization 헤더 조차 포함되지 않습니다.

이로 인해 Simple Request는 일반적인 상황에서는 거의 발생하지 않는 요청입니다.

 

 

 

 

 

 

 

📗 Simple Request 시나리오

아래와 같은 코드를 통해 https://bar.other로 요청을 보내는 상황을 가정하겠습니다.

const xhr = new XMLHttpRequest();
const url = 'https://bar.other/resources/public-data/';

xhr.open('GET', url);
xhr.onreadystatechange = someHandler;
xhr.send();

 

이 경우 Simple Request 조건에 모두 부합하기 때문에, Simple Request가 발생합니다.

 

이때 브라우저와 서버간의 요청과 응답 내용은 다음과 같습니다.

 

 

🌱 요청

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101
Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive Origin: https://foo.example
Origin: https://foo.example

요청 헤더의 Origin을 보면 https://foo.example로부터 요청이 왔다는 것을 알 수 있습니다.

 

 

 

🌱 응답

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

서버는 해당 요청에 대한 응답으로 Access-Control-Allow-Origin 헤더를 전송합니다.

이때 서버는 와일드카드(*)를 사용하여 모든 Origin에 대한 요청을 허용했기 때문에 해당 요청은 성공합니다.

 

만약 https://bar.example 서버에선 오직 https://foo.example 의 요청만을 허용하려고 한다면, 다음과 같이 설정해야 합니다.

Access-Control-Allow-Origin: https://foo.example

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 Preflight Request

Simple Request와는 달리 본 요청을 보내기 전에 OPTIONS 메서드를 통해서 미리 HTTP 요청을 보내 본 요청을 전송하기에 안전한지 확인하는 요청입니다.

(즉 요청은 2번 발생하며, Preflight 요청은 브라우저가 알아서 보내는 것이므로 따로 Preflight 요청을 작성하여 보낼 필요가 없습니다.)

 

 

 

 

 

 

📕 Preflight Request 시나리오

아래와 같은 코드를 통해 https://bar.other로 요청을 보내는 상황을 가정하겠습니다.

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://bar.other/doc");
xhr.setRequestHeader("X-PINGOTHER", "pingpong");
xhr.setRequestHeader("Content-Type", "text/xml");
xhr.onreadystatechange = handler;
xhr.send("<person><name>Arun</name></person>");

 

 

클라이언트와 서버간의 전체 통신 내용은 다음과 같습니다.

 

 

 

🌱 Preflight 요청

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101
Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

OPTIONS 메서드를 통해 Preflight Request를 전송합니다.

Preflight Request를 전송할 때에는 Access-Control-Request-Method와 Access-Control-Request-Headers라는 두 개의 요청 헤더가 추가로 전송됩니다.

 

 

 

 

 

🌱 Preflight 응답

HTTP/1.1 204 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive

우선 Access-Control-Allow-Origin에 https://foo.example이 포함되어 있으므로 https://foo.example의 요청은 허용합니다.

Access-Control-Allow-Methods 헤더에는 POST, GET, OPTIONS 메서드를 허용한다고 명시되어 있습니다.

Access-Control-Allow-Headers 헤더는 X-PINGOTHER, Content-Type 이라는 헤더를 허용한다는 의미입니다.

이를 통해 브라우저는 X-PINGOTHER와 Content-Type이라는 헤더를 본 요청에서 사용할 수 있다는 것을 알게됩니다.

마지막으로 Access-Controler-Max-Age는 다른 Preflight Request를 보내지 않고, preflight request에 대한 응답을 캐시할 수 있는 시간(초)를 제공합니다.

해당 서버에서는 86400초로 설정되어 있습니다.

 

 

 

 

 

🌱 실제 요청

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101
Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: https://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: https://foo.example
Pragma: no-cache
Cache-Control: no-cache <person><name>Arun</name></person>

 

 

🌱 응답

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

 

 

 

 

 

 

📙 참고: Vary

서버가 Access-Control-Allow-Origin: * 대신에 특정한 origin을 지정한 경우,
서버는 Vary 응답 헤더에 Origin을 포함해야 합니다.

 

 

 

 

 

 

 

 

 

📒 Preflight를 사용하는 이유

CORS의 매커니즘을 살펴보면 다음과 같은 문제점이 있습니다.

1. 클라이언트가 서버로 요청을 보낸다.
2. 서버는 해당 요청을 처리한다.
3. 서버에서 요청 처리 결과를 응답한다.
4. 클라이언트(브라우저)에서 응답을 받고, CORS 정책 위반인지 확인한다.
5. 정책 위반이라면 해당 응답을 버린다. (응? 이미 서버는 요청을 처리했는데..?)

만약 CORS 정책에 위반하는 요청이 서버의 DB를 모두 지운다던가, 사용자를 탈퇴시키는 등 서버의 리소스에 영향을 주는 요청이라면 서버는 이미 해당 요청을 처리했기 때문에 문제가 발생할 수 있습니다.

 

따라서 서버의 리소스를 변경할 가능성이 있는 요청(Simple Request의 조건에 부합하지 않는 요청)에 대해서는 해당 요청이 서버에 보내도 안전한지를 먼저 확인해야 하는 작업이 필요하며, 이를 위해 Preflight가 등장하게 되었습니다.

(Simple Request는 요청이 서버의 리소스를 변경하지 않기 때문에 Preflight 요청이 발생하지 않는다고 하였지만, 이는 서버의 구현에 따라 충분히 서버의 리소스가 변경되게 만들 수 있으므로 서버 개발자는 이를 항상 염두해 두고 개발을 해야 합니다.)

 

Preflight Request 방식은 요청이 총 2번 발생하기 때문에 성능에 영향을 줄 수 있습니다.

 

그래서 Preflight 요청의 응답을 캐싱하여 특정 기간 동안은 다시 Preflight 요청을 발생시키지 않도록 할 수 있는데요, 

Access-Control-Max-Age에 Preflight 요청의 캐싱 기간을 지정해줄 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 Credentialed Request

credentials 플래그가 true인 요청의 경우 Credentialed Request를 사용하게 됩니다.

 

기본적으로 교차 사이트(Cross-Site)간 XMLHttpRequest 혹은 Fetch 요청에서 브라우저는 인증 관련 정보를 보내지 않습니다.

 

credentialed 요청을 보내기 위해서는 이를 설정해 주어야 하는데요,

Fetch api의 경우 credentials 옵션을 설정하여 인증 정보를 보낼 수 있으며, 다음과 같은 종류가 있습니다.

옵션	설명
same-origin (default)	같은 출처로의 요청에만 인증 정보를 담음
include	모든 요청에 인증 정보를 담음
omit	모든 요청에 인증 정보를 담지 않음

fetch('http://bar.other/resources/credentialed-content/', {
  credentials: 'include', // Credentials 옵션 변경!
});

 

 

XMLHttpRequest는 아래와 같이 특정 플레그를 설정하여야 합니다.

const invocation = new XMLHttpRequest();
const url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain() {
  if (invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;  // 인증 정보 보내기 위함
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

 

 

 

 

 

 

📕 Credentialed Request 시나리오

위 XMLHttpRequest를 예시로 계속 살펴보겠습니다.

우선은 Simple Request 조건에 부합하므로 Preflight 되지 않습니다.

 

이후 클라이언트(브라우저)는 서버의 응답 헤더에 Access-Control-Allow-Credentials: true가 없다면 해당 응답을 거부합니다.

 

이는 서버의 응답에 Access-Control-Allow-Credentials : true가 존재하므로 성공합니다.

 

이들간의 요청과 응답은 다음과 같습니다.

 

 

 

 

🌱 요청

GET /resources/credentialed-content/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101
Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2

쿠키가 포함되기 때문에 credentialed request 입니다.

 

 

 

🌱 응답

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]

만약 Access-Control-Allow-Credentials: true가 없다면 응답은 무시됩니다.

 

 

 

 

 

 

 

 

📙 Credentialed Request와 와일드카트

Credentialed Request에 응답할 때 서버는 반드시 와일드카드(*)를 지정하는 대신
Access-Control-Allow-Origin 헤더 값에 출처를 지정해야 합니다.

예를 들어 위 시나리오의 요청 헤더에는 Cookie가 포함되어 있으므로 Credentialed Request이며,

서버에서 Access-Control-Allow-Origin: * 으로 설정했다면 실패하게 됩니다.

 

(Access-Control-Allow-Origin: * 을 한 상태에서 Access-Control-Allow-Credentials: true를 설정할 수 없습니다.)

 

 

 

 

 

 

 

 

 

🧐 헤더 살펴보기

(위에서 나오지 않았거나 추가 설명이 필요한 헤더만 살펴보겠습니다)

 

 

 

📕 Access-Control-Expose-Headers

브라우저에는 기본적으로 CORS 허용 목록 응답 헤더만 노출되지만, 브라우저가 다른 헤더에 액세스할 수 있도록 할 때 사용합니다.

예를 들어 서버가 어떤 요청의 응답으로 Location 헤더를 반환한다면, Access-Control-Expose-Headers: Location을 통해 브라우저에서 Location 헤더에 접근할 수 있도록 해주어야 합니다.

 

 

 

 

 

📙 Access-Control-Allow-Credentials

credentials 플래그가 true인 요청에 대한 응답을 표시할 수 있는지를 나타냅니다.

 

Preflight request에 대한 응답의 일부로 사용되는 경우에는 credentials를 사용하여 실제 요청을 수행할 수 있는지를 나타냅니다.

Simple reqeust의 경우 preflight되지 않으므로 credentials 요청에 대한 응답으로 Access-Control-Allow-Credentials: true가 없다면 응답 결과는 무시됩니다.

 

 

 

 

 

 

 

 

 

📚 Reference

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS#requests_with_credentials

교차 출처 리소스 공유 (CORS) - HTTP | MDN

https://fetch.spec.whatwg.org/#http-cors-protocol

Fetch Standard