CORS

CORS란?

CORS (Cross Origin Resource Sharing)란 도메인이 다른 2개의 사이트가 데이터를 주고 받을 때 발생하는 문제이다. 예를 들어 custom-domain.com에서 custom2-domain.com으로 데이터를 요청한다고 할 때, 별도의 설정이 없으면 CORS를 만나게 될 것이다.

CORS가 생기게 된 이유는 서버 내에서 요청이 허락된 도메인에만 데이터를 주면서 보안을 강화하기 위해서이다. 요청을 허락하기 위해서는 Access-Control-Alow-Origin: {도메인}과 같은 설정을 Response 헤더에 추가해야 한다.

만약 도메인을 와일드카드(*)로 설정하면 모든 도메인에 대한 요청을 허용할 수 있다. 그 외의 헤더도 설정 가능하다.

• Access-Control-Allow-Orgin : 요청을 보내는 페이지의 출처 [ *, 도메인 ]

• Access-Control-Allow-Methods : 요청을 허용하는 메소드. Default : GET, POST

• Access-Control-Max-Age : 클라이언트에서 preflight 요청 (서버의 응답 가능여부에 대한 확인) 결과를 저장할 시간

• Access-Control-Allow-Headers : 요청을 허용하는 헤더

자유롭게 다른 Origin으로 요청을 보낼 수 있게 된다면?

악의적인 마음을 품은 해커가 자신의 웹사이트를 구축해놓고, 이 웹사이트를 가리키는 링크를 담은 메일을 사용자에게 보내는 것이다. 그리고 이 사용자는 A라는 웹사이트에 로그인이 되어 있어서 브라우저 단에 인증 정보가 존재한다고 해보자. 만약 그 사용자가 실수로 해당 링크를 클릭하여 해커의 웹사이트에 접속하면, 해커가 심어둔 JavaScript 코드가 실행되어 자기도 모르게 A 웹사이트로 개인 정보를 조회하는 API 요청을 보낼 것이다. 이 사용자의 브라우저 단에는 인증 정보가 존재하기 때문에, 이것이 해당 요청에 함께 실어서 전송되면 서버는 인증된 요청이라 생각하여 개인 정보를 응답해줄 것이다. 그러고 나면 그 개인 정보를 해커가 빼돌릴 수 있게 된다. (이것이 바로 CSRF 공격이다.)

만약 SOP가 존재한다면 이런 문제를 어느정도 예방할 수 있다.

Origin

CORS에서 Origin은 URL에서 프로토콜, 도메인, 포트 번호를 합친 것을 의미한다.

다음과 같은 URL이 존재할 때, https://custom-domain.com:9091/pp/1234

프로토콜(Scheme) : https://

도메인 : custom-domain.com

포트 : 9091

여기서 Origin은 포트 번호까지 해당한다.

SOP (Same Origin Policy)

SOP는 다른 Origin으로 요청을 보낼 수 없도록 금지하는 정책이다. 따라서 동일한 Origin으로만 요청을 보내도록 한다. 최근 기술의 발전으로 서로 다른 Origin끼리 데이터를 주고받는 경우가 많아지게 되고 SOP는 별도 예외 사항을 두게된다. 즉, 특정 상황에 서로 다른 Origin끼리 요청을 보내도록 하는것이다.

CORS는 다른 Origin으로 요청을 보내기 위해 지켜야 하는 정책으로써 원래라면 SOP에 의해 막히게 될 요청을 풀어주는 정책이라고 생각하면 된다.

• 요청을 막아주는 정책인줄 알았는데 오히려 요청을 보내도록 도와주는 정책인것임ㅋㅋ..

여기서 중요한 것은 CORS는 '브라우저'의 정책이다. 그렇기 때문에 브라우저가 자신이 보낸 요청 및 서버로부터 받은 응답이 CORS 정책을 지키는지 검사한다. 실제 브라우저의 기본 CORS 정책은 다른 출처로부터의 요청이 리소스에 접근하는 것을 허용하지 않는다. 만약 서버에서 보낸 응답이 안전한 요청이 아니라고 판단하면 해당 요청을 버린다.

CORS 동작 원리

동작 원리는 단순하다. 브라우저는 다른 Origin으로 요청을 보낼 때 Origin 헤더에 자신의 Origin을 설정하고 서버로부터 응답을 받으면 응답의 Access-Control-Allow-Origin 헤더에 설정된 Origin 목록을 확인한다.

• 브라우저는 서버에서 설정한 응답의 Origin 목록을 확인한다.

그래서 서버에서 Origin 목록을 설정하거나 와일드카드(*)를 설정한다.

• 와일드카드(*)는 모든 Origin을 허용한다는 것을 의미하는 기호이다.

CORS 요청에는 세 가지 유형이 존재한다.

1. 단순 요청 (Simple Request)

서버에서 요청을 보내고 서버로부터 응답이 도착했을 때, 브라우저가 요청한 Origin과 응답 헤더의 Access-Control-Request-Headers의 값을 비교해서 유효한 요청이면 리소스를 응답한다. 만약 유효하지 않다면 브라우저는 이를 막고 에러를 발생시킨다.

HTTP Method가 다음중 하나이어야 한다.

• GET, HEAD, POST

User Agent가 자동으로 설정한 헤더를 제외하면, 다음과 같은 헤더만 사용할 수 있다. 즉, 자동으로 설정되는 헤더는 제외하고 다음 헤더만 사용이 가능하다.

• Accept, Accept-Language => Cotent-Language, Content-Type

Content-Type은 다음과 같은 경우

• application/x-www-form-urlencoded

• multipart/form-data

• text/plain

위 조건을 만족하는 요청을 안전한 요청으로 취급하고 Simple Requests라고 부른다.

이 요청은 추가적으로 확인하지 않고 실제 요청을 보낸다.

2. 프리플라이트 요청 (Preflight Request)

Simple Request 조건에 벗어난 요청같은 경우, 서버에서 실제 요청을 보내기 전에 예비 요청에 해당하는 Preflight Request을 먼저 보내서 실제 요청이 전송하는데 있어서 안전한지 판단한다. 만약 안전한 요청이라고 확인되면 실제 요청을 서버에 보낸다. 그래서 총 두 번의 요청을 보낸다.

요청은 다음과 같다.

• 메소드로 OPTIONS를 사용한다.

• Origin 헤더에 자신의 Origin을 설정한다.

• Access-Control-Request-Method 헤더에 실제 요청에 사용할 메소드를 설정한다.

• Access-Control-Request-Headers 헤더에 실제 요청에 사용할 헤더들을 설정한다.

쉽게 얘기하면, Origin 헤더에 현재 요청하는 Browser Origin과, Access-Control-Request-Method 헤더에 요청하는 HTTP Method와 Access-Control-Request-Headers 요청 시 사용할 헤더를 OPTIONS 메서드로 서버에 요청한다. 이때 내용물은 없고 헤더만 전송한다. 이 요청이 유효하면 원래 보내려고 했던 요청을 보낸다.

서버는 Preflight Request 요청에 다음과 같은 특징을 가진 응답을 제공해야 한다.

• Access-Control-Allow-Origin 헤더에 허용되는 Origin들의 목록 혹은 와일드카드(*)를 설정한다.

  • Browser가 해당 origin이 자원에 접근할 수 있도록 허용한다. 와일드카드(*)는 credentials이 없는 요청에 한해서 모든 origin에서 접근이 가능하도록 허용한다.

• Access-Control-Allow-Methods 헤더에 허용되는 메소드들의 목록 혹은 와일드카드(*)를 설정한다.

  • preflight 요청에 대한 응답으로 허용되는 메서드들을 나타낸다.

• Access-Control-Allow-Headers 헤더에 허용되는 헤더들의 목록 혹은 와일드카드(*)를 설정한다.

  • preflight 요청에 대한 응답으로 실제 요청 시 사용할 수 있는 HTTP 헤더를 나타낸다.

• Access-Control-Max-Age 헤더에 해당 프리플라이트 요청이 브라우저에 캐시 될 수 있는 시간을 초 단위로 설정한다.

  • 얼마나 오랫동안 preflight 요청이 캐싱 될 수 있는지를 나타낸다.

Browser는 위와 같은 응답을 받으면 응답 정보를 자신이 전송한 요청의 정보와 비교하여 실제 요청의 안전성을 검사한다. 안전하다고 판단되면 실제 요청을 서버에 전송한다. 이때 Access-Control-Request-XXX 형태의 헤더는 보내지 않는다.

사용자가 정의한 헤더(New-Header)를 사용하는 요청의 경우 Simple Request 조건에 벗어나기 때문에 Preflight 요청이 필요하다.

3. 인증 정보를 포함한 요청 (Credentialed Request)

1번과 2번 요청은 인증 정보가 없는 경우에 해당한다.

여기서 인증 정보는 쿠키(Cookie) 혹은 Authorization 헤더에 설정하는 토큰 값 등을 얘기한다.

이러한 인증 정보를 함께 보내야하는 요청은 별도의 CORS 정책이 존재한다.

쿠키 같은 인증 정보를 보내기 위해서는 클라이언트에서 요청 시 별도의 설정이 필요하다.

이는 Ajax 요청을 위해 어떠한 도구를 사용하느냐에 따라 달라지는데 만약 XMLHttpRequest, JQuery의 ajax, 또는 axios를 사용한다면 withCredentials를 true로 설정해야 한다.

반면 fetch API를 사용한다면 credentials 옵션을 include로 설정한다.

이러한 설정을 해주지 않으면 쿠키 등의 인증 정보는 절대로 서버에게 전송되지 않는다.

이외의 응답 헤더

• Access-Control-Allow-Credentials

  • credentials가 true일 때 요청에 대한 응답이 노출될 수 있는지를 나타낸다.

  • preflight 요청에 대한 응답의 일부로 사용되는 경우 실제 자격 증명을 사용하여 실제 요청을 수행할 수 있는지 나타낸다.

  • 간단한 GET 요청은 preflight되지 않으므로 자격 증명이 있는 리소스를 요청하면 헤더가 리소스와 함께 반환되지 않으며 Browser에서 응답을 무시한다.

• Access-Control-Expose-Headers

  • Browser가 액세스할 수 있는 서버 화이트리스트 헤더를 허용한다.

Summary

CORS는 사용자를 보호하기 위한 "웹 브라우저" 보안 정책이다. 서버의 보안 정책이 아니다.

그래서 처음에 서버랑은 연관이 없는건가 생각했다.

CORS 정책은 서버에서 결정(설정)하고, 이 정책의 준수 여부는 브라우저가 실행한다.

즉, 브라우저는 서버가 설정한 정책을 해석하고 이를 기반으로 js 코드가 어떤 데이터에 접근할 수 있는지를 결정한다.

sources

https://fetch.spec.whatwg.org/#http-cors-protocol https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests