HTML5와 함께 도입된 CORS는 사용자로 하여금 SOP(Same Origin Policy)의 제한을 극복하고
Cross-Origin HTTP 요청을 수행할 수 있게 만들어주었다.
서버의 위치를 의미하는 URL은 마치 하나의 문자열 같아 보여도 여러개의 구성요소로 이루어져있다.
위와 같이 포트 번호까지 전부 일치해야지만 동일한 Origin이라고 할수 있다.
언듯 보면 유용하기만 할것 같은 CORS이지만 정확한 방법으로 사용하지 않는다면 개발자에게 끔찍한 오류 메시지를 보여주는 녀석이라고 한다.
CORS의 동작원리는 기본적으로 브라우저에서 다른 Origin으로 쵸청을 보낼시, 헤더에 자신의 Origin을 설정하고, 서버로부터 응답을 받으면 응답반은 헤더에 설정된 Origin의 목록에 요청의 Origin 헤더값이 포함되어 있는지 검사하는것.
하지만 CORS는 크게 3가지 유형으로 분류 가능하다.
단순 요청을 하기 위한 조건.
위의 조건을 만족하는 요청은 안전한 요청으로 취급되어, 단 한번의 요청만을 전송한다.
위의 단순 요청의 조건에 만족하지 못하는 요청의 경우, 서버에 실제 요청을 보내기 전에 프리플라이트 요청을 통해 안전 여부를 확인한다.
위에서 소개한 두 유형의 요청은 인증 정보가 없는 경우였다. 만약 이러한 인증 정보를 함께 보내야 하는 요청(Credentialed Request)이라면, 별도로 따라줘야 하는 CORS 정책이 존재한다.
우선, 쿠키 등의 인증 정보를 보내기 위해서는 클라이언트 단에서 요청 시 별도의 설정이 필요하다. 이는 Ajax 요청을 위해 어떠한 도구를 사용하느냐에 따라 달라진다. 만약 XMLHttpRequest, jQuery의 ajax, 또는 axios를 사용한다면 withCredentials 옵션을 true로 설정해줘야 한다. 반면, fetch API를 사용한다면 credentials 옵션을 include로 설정해줘야 한다. 이러한 별도의 설정을 해주지 않으면 쿠키 등의 인증 정보는 절대로 자동으로 서버에게 전송되지 않는다.
위와 같은 설정을 통해 인증 정보를 요청에 포함시켰다면, 이 요청은 이제 인증 정보를 포함한 요청이 된다. 그리고 서버는 이러한 요청에 대해 일반적인 CORS 요청과는 다르게 대응해줘야 한다. 응답의 Allow-Control-Allow-Origin 헤더가 와일드카드(*)가 아닌 분명한 Origin으로 설정되어야 하고, Allow-Control-Allow-Credentials 헤더는 true로 설정되어야 한다. 그렇지 않으면 브라우저에 의해 응답이 거부된다. 이를 그림으로 나타내면 다음과 같다