CORS란

프로젝트 중 CORS(Crose-Origin Resource Sharing) 정책위반으로 인해 에러가 발생하는 상황을 겪었다.

Cross-Origin Resource Sharing(CORS)

교차 출처 리소스 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

 

출처는 Protocol과 Host, Post까지 모두 합친 것을 의미한다.

 

Same-Origin Policy(SOP)

웹에서는 다른 출처의 리소스 요청을 제한하는 것과 관련된 두가지 정책이 존재한다. 한 가지는 이 포스트의 주제인 CORS 다른 한가지는 SOP(Same-Origin Policy)이다. SOP는 "같은 출처에서만 리소스를 공유할 수 있다"라는 규칙을 가진 정책이다. 그러나 웹에서는 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이라 무작정 막을수도 없기에 몇가지 예외조항을 두고 이 조항에 해당하는 리소스 요청은 리소스의 출처가 다르더라도 허용하기로 했는데, 그중 하나가 "CORS 정책을 지킨 리소스 요청"이다.

CORS 기본 동작 과정

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

Origin: https://velog.io

이후 서버가 요청에 대한 응답을 할 때 응답 헤더의 Access-Countrol-Allow-Origin이라는 값에 접근이 허용된 출처를 알려주고 응답을 받은 브라우저는 클라이언트가 보낸 요청의 Origin과 서버가 보낸준 응답의 Access-Countrol-Allow-Origin을 비교하여 이 응답이 유효한 응답인지 아닌지 결정한다

 

기본적인 흐름은 간단하지만 CORS가 동작하는 방식은 한가지가 아닌 세가지 시나리오에 따라 변경된다.

CORS의 3가지 시나리오

실제 CORS가 동작하는 방식은 3가지 시나리오에 따라 변경된다.

 

예비요청 (Preflight Request)

브라우저는 요청을 한번에 보내지 않고, 예비요청과 본요청으로 나누어 서버에 전달한다.

이때 브라우저가 예비요청을 보내는 것을 Preflight라고 부르며

이 예비요청의 메소드에는 OPTIONS가 사용된다.

예비요청의 역할은 본 요청을 보내기 전에 브라우저 스스로 안전한 요청인지 확인하는 것이다.

 

단순 요청 (Simple Request)

단순요청은 예비 요청(Prefilght)을 보내지 않고 바로 서버에 본 요청을 한 후,

서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 같을 보내주면 브라우저가 CORS정책 위반여부를 검사하는 방식이다.

 

인증된 요청 (Credentialed Request)

기존 예비요청에서 보안을 더 강화하고 싶을 때 사용한다.

기본적으로 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는

별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다.

따라서, 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 있는데 바로 credentials 옵션이다.

이 옵션은 총 3가지 값을 사용할 수 있다.

 

출처 : https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

출처 : https://velog.io/@jimmy0417/WEB-CORS-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%A0%81%EC%9A%A9-%EB%B0%A9%EB%B2%95