CORS (Cross Origin Resource Sharing) ?
CORS (Cross Origin Resource Sharing) ?
CORS는 Cross-Origin Resource Sharing의 약자로 직역하면 "교차 출처 리소스 공유" 이다.
좀 더 쉽게 말하면 동일한 출처가 아닌 다른 출처에서 데이터를 주고 받는 것을 허용하는 정책이다.
CORS에 대해 설명하려면 그 전에 SOP를 설명해야 된다.
SOP (Same Origin Policy)
SOP는 동일 출처 정책으로 웹 브라우저에서 보안을 강화하기 위하여
동일한 출처에서만 리소스를 주고 받도록 하는 정책이다.
그렇다면 "출처"는 도대체 무엇일까?
쉽게 말하면 URL 주소이다
하지만 "동일한 출처"는 정확히 똑같은 URL을 의미하는 것을 아니다.
동일한 출처는 URL 중에서도 프로토콜, 도메인 주소, 포트 번호가 같은 것을 의미한다.
CORS
다시 CORS로 돌아와서 이러한 동일 출처 정책이 있기 때문에 원래는 다른 출처에서 리소스를 받아오는 것이 제한된다.
하지만 다른 출처로부터 리소스를 받아오는 것은 필수 요소가 되었고, 이러한 문제를 해결하기 위해 나온 정책이 바로 CORS(교차 출처 자원 공유)이다.
CORS는 어떻게 안전하게 다른 출처와 리소스를 공유하는지 확인해보면
바로 두 가지 방법이 있는데, 단순 요청 방법과 예비 요청 방법이 있다.
Simple Request
어떤 요청들은 CORS Preflight Request(사전 요청)을 발생시키지 않습니다. 보통 이런 요청들을 Simple Request라고 한다.
Simple Request의 경우에는 아래 3가지 조건이 모두 만족되는 경우를 말한다.
- GET / HEAD / POST 중 한 가지 메소드를 사용해야 한다.
- User agent에 의해 자동으로 설정되는 헤더(Connection, User-Agent 또는 Fetch spec에서 '금지된 헤더 이름(forbidden header name)'으로 정의된 이름들을 가진 헤더들)을 제외하고, Fetch spec에서 'CORS-safelisted request-header'라고 정의되어있고 수동 설정이 허용된 헤더들은 다음과 같다.
- Accept
- Accept-Language
- Content-Language
- Content-Type (but note the additional requirements below)
- DPR
- Downlink
- Save-Data
- Viewport-Width
- Width
- 오직 아래의 Content Type만 지정해야 한다.
- application / x-www-form-urlencoded
- multipart/form-data
- text/plain
Preflight request
W3C 명세에 의하면 브라우저는 먼저 서버에 Preflight request(예비 요청)를 전송하여 실제 요청을 보내는 것이 안전한지 OPTIONS method로 확인한다. 그리고 서버로부터 유효하다는 응답을 받으면 그 다음 HTTP request 메소드와 함께 Actual request(본 요청)을 보낸다. 만약 유효하지 않다면 에러를 발생시키고 실제 요청은 서버로 전송하지 않는다.
이러한 예비 요청과 본 요청에 대한 서버의 응답은 프로그래머가 구분지어 처리하는 것은 아니다. 프로그래머가 Access-Control- 계열의 Response Header만 적절히 정해주면 Options 요청으로 오는 예비 요청과 GET, POST, PUT, DELETE 등으로 오는 본 요청의 처리는 서버가 알아서 처리한다.
Preflight request는 GET, HEAD, POST외 다른 방식으로도 요청을 보낼 수 있고 application/xml처럼 다른 Content-type으로 요청을 보낼 수도 있으며, 커스텀 헤더도 사용할 수 있다.