CORS

CORS란?

SOP의 시나리오와 CORS 시나리오를 설명한 사진

• Cross-Origin Resource Sharing (교차 출처 리소스 공유)
• 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제
• 출처는 도메인, 프로토콜, 포트가 모두 동일함을 뜻함
• 브라우저에서는 동일 출처 정책 (SOP) 로 인해 다른 출처 간 자원(데이터) 이동이 금지

SOP (Same-Origin Policy)

CORS를 알아보기 전 먼저 SOP에 대해 알아보자

• 교차 출처 정책으로 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한함
• XMLHttpRequest(fetch() 와 같은)요소를 사용할 때 상호작용을 통제
  • Chrome의 개발자 도구에서 Fetch/XHR 항목
    

SOP, CORS에서 Origin (출처) 이란?

• 출처는 Protocol, Host, Port가 모두 동일할 때 동일 출처라고 한다.
• 위의 예시에서 https는 443포트를 사용함으로 생략 가능하다.
• https://velog.io:443/@k-moovie 는 동일 출처이다

CORS란?

• 웹 기술이 발전함에 따라 브라우저에서 다른 사이트의 자원(이미지와 같은)을 요청할 수 있다.

• 기본적으로 웹 클라이언트 어플리케이션이 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 request를 보낸다

• 이 때 브라우저는 request header의 Origin필드에 요청을 보내는 출처를 함께 담아 보낸다.

  Origin: https://velog.io/@k-moovie

• 이후 서버에서 응답을 보낼 때 response header의 Access-Control-Allow-Origin 필드에 '이 리소스를 접근하는 것이 허용된 출처'를 전송한다.

• 브라우저는 자신이 보낸 Origin과 서버에서 온 응답의 Access-Control-Allow-Origin를 비교해 같다면 허용한다.

CORS의 다양한 시나리오

Preflight Request

• 일반적으로 웹 어플리케이션을 개발할 때 흔히 마주하는 시나리오
• 예비 요청과 본 요청으로 두 번 전송

OPTIONS https://velog.io/@k-moovie

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ko;q=0.8,ja;q=0.7,la;q=0.6
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: GET
Connection: keep-alive
Host: velog.io
Origin: https://velog.io
Referer: https://velog.io/@k-moovie/user
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site

• 예비 요청은 method가 OPTIONS로 전송된다
  • 본 요청에 사용할 다른 정보를 (method, header 등) 같이 전송한다.

OPTIONS https://velog.io/@k-moovie 200 OK

Access-Control-Allow-Origin: https://velog.io
Content-Encoding: gzip
Content-Length: 699
Content-Type: text/xml; charset=utf-8
Date: Sun, 24 May 2020 11:52:33 GMT
P3P: CP='ALL DSP COR MON LAW OUR LEG DEL'
Server: Apache
Vary: Accept-Encoding
X-UA-Compatible: IE=Edge

• 서버는 예비 요청의 응답으로 Access-Control-Allow-Origin을 반환한다.

Simple Request

• 서버에 곧바로 요청을 보내는 것으로 서버는 다른 출처의 요청을 가리지 않으므로 사용 시 주의가 필요하다
• Preflight Request에서 예비 요청을 제거한 것
• 아래의 제한 사항이 있다

  • 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.
  • Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
  • Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.

Credentialed Request

• 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법
• 기본적으로 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다
• 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션
• 아래와 같은 제한 사항이 있다

  • Access-Control-Allow-Origin에는 *를 사용할 수 없으며, 명시적인 URL이어야한다.
  • 응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야한다.

더 알아보기

Spring에서 CORS를 해결하는 방법

• Servlet Filter를 사용하여 커스텀한 Cors 설정
• WebMvcConfiguer를 구현한 Configuration 클래스를 만들어서 addCorsMappings()를 재정의
• Spring Security에서 CorsConfigurationSource를 Bean으로 등록하고 config에 추가

Reference

• 교차 출처 리소스 공유 (CORS)
• CORS는 왜 이렇게 우리를 힘들게 하는걸까?
• 웹개발 짜증유발자! CORS가 뭔가요?
• CORS 우회를 위한 자바스크립트(POST) 실험
  
• [10분 테코톡] 🌳 나봄의 CORS