[Web] CORS(Cross-Origin Resource Sharing)

🎯 목표 : CORS의 기본 개념 이해 

📒 CORS

• Cross-Origin Resource Sharing의 약자이며, 웹 애플리케이션에서 다른 출처의 선택한 자원에 접근할수 있는 권한을 부여하도록 알려주는 체제다.
• 리소스가 자신의 출처(프로토콜, 호스트(포트포함))와 다를때 교차 출처 HTTP 요청을 실행한다.

---

📌 출처(Origin)란?

• CORS가 무엇인지 알기 위해서는 출처가 무엇인지, SOP가 무엇인지 먼저 이해가 필요했다.
• 출처는 URL에서 Protocol과 Host를 출처라 하며, 이때 출처는 Port까지 포함한다.
• https://sussa1933.tistory.com/manage/newpost/
• 위 블록 부분이 출처라 할수 있겠다.

---

📌 SOP(Same-Origin Policy)

• 웹에서 다른 출처로의 리소스 요청을 제한하는 것과 관련된 정책이며,
• SOP는 같은 출처에서만 리소스를 공유할수 있다라는 규칙을 가진 정책이라 할수 있다.
• 하지만, 웹에서 다른 출처의 리소스를 가져와 사용하는 일은 아주 흔한일이고, 이 때문에 몇가지 예외를 두고 출처가 다르더라도 리소스 요청이 허용 되는데, 그 중 하나가 CORS 정책에 허가된 리소스 요청이다.

👉 같은 출처의 기준?

• 기본적으로 브라우저는 String Value를 비교하여 출처를 판단한다.
• http://localhost 와 같은 출처로는 http://localhost:80 , http://localhost/api/cors
• 다른 출처로는 http://127.0.0.1로 예를 들수 있겠다.
• 실제로 접속을 해보면, 같은곳을 출력하지만 출처는 다르다.
• 이 출처를 비교하고 판단하는 로직은 서버에 구현된 로직이 아니라 브라우저에 구현되어 있는 로직이다.
• 즉, CORS를 위반한 리소스 요청을 하더라도, 응답 서버에서 같은 출처의 요청만 받겠다는 로직을 가지고 있는 경우가 아니라면, 서버는 정상적으로 응답을 하게되고, 응답을 받은 브라우저는 CORS 위반이라 판단하여, 서버에서 보내온 응답을 폐기한다.
• 서버 간 통신을 할때는 CORS가 적용되지 않으며 응답을 받은 브라우저에서는 CORS 위반으로 에러가 발생하더라도 서버의 로그는 정상적으로 응답을 했다는 로그만 남기 때문에 에러를 찾는데 어려움을 겪을수도 있다.

---

📒 CORS의 동작 방식

• 웹 애플리케이션에서 다른 출처의 리소스를 요청할 때 HTTP 요청 Header에 Origin이 필드가 있으며 해당 필드에 출처를 함께 담아 보낸다.
• 서버가 요청에 대한 응답을 할때 응답 Header에 Access-Control-Allow-Origin이라는 값에 요청 출처가 들어가고 Acces-Control-Allow-Credentials 의 값을 응답하며, 브라우저는 요청 했던 Origin과 Access-Control-Allow-Origin을 비교한 후 유효한 응답인지 아닌지 결정한다.
• 위 흐름은 기본적인 흐름일 뿐 각 요청의 방식과 상황에 따라 다른 방식으로 동작한다.

---

📌 Preflight Request

• 프리플라이트 방식은 실제 요청을 보내는 것이 안전한지 확인 하기 위해 먼저 메소드를 사용하여 다른 출처의 리소스에 HTTP 요청을 보낸다. 이때 사용하는 메소드는 OPTIONS 이다.

• 위 그림과 같이 https://foo.example 에서 POST 메소드를 사용하여 웹 서버로 요청을 보냈다고 한다면,

• POST 요청을 하기전 OPTIONS 메소드를 사용하여 요청 메소드, Content-Type등 요청 정보를 메세지에 담아 사전 요청을 한다.

• OPTIONS 요청을 받은 서버에서는 요청 정보에 따른 리소스 접근을 허용하는 Access-Control-Allow-Origin과 Acces-Control-Allow-Methods 등의 정보를 응답해준다.

• 브라우저는 응답을 확인 한 후 실제 요청하고자하는 POST 요청을 하게 된다.

• 위 그림은 정상적인 요청과 응답이지만,
  만약 서버에서 사전 요청에 대한 응답으로 Access-Control-Allow-Origin의 값이 다른 출처를 가리킨다면, 가리키고 있는 출처만 리소스 접근을 허용하고 있으므로, 사전요청에 대한 응답을 받은 브라우저는 CORS 에러를 발생하게 될것이다.

• 사전 요청에 응답 성공 여부와 상관 없이 CORS 에러가 발생할 수도 있다. 이때는 CORS 에러가 발생한 시점이 사전 요청에 대한 응답을 받고 난 직후이기 때문이다. 프리플라이트 요청에서 검사한 정보에서 추가된 정보가 있거나 메인 요청의 출처가 달라 졌기 때문에 본 요청에서 CORS 에러가 발생할수도 있다.

• 각 요청, 응답 메세지에서의 항목들을 정리하자면,

  • Origin : 요청측 출처 정보
  • Access-Control-Allow-Origin : 서버에서 허용된 출처
  • Acces-Control-Allow-Methods : 요청 측에서는 사용할 메소드. 서버 측에서는 허용된 메소드.
  • Acces-Control-Allow-Header : 요청 측에서는 유효한 Header인지 요청, 서버 측에서는 허용되는 Header 정보
  • Acces-Control-Max-Age : 서버가 프리플라이트 요청에 대한 유효한 응답 수명. // sec

---

📌 Simple Request

• 단순 요청은 사전 요청을 보내지 않고 바로 서버에게 요청하고자 하는 본 요청을 하게된다.
• 본 요청을 할때 Origin 출처를 요청 메세지에 포함하여 보내주고, 서버에서 응답으로 Access-Control-Allow-Origin을 받아 그때서야 브라우저에서는 COSS 위반 여부를 판단한다.
• 이때, 이미 서버에서는 정상적인 응답과 처리를 한 상태이며, 응답을 받은 브라우저에서 CORS 위반으로 에러가 발생하더라도 서버에서의 요청에 대한 처리는 이미 끝난 상태인 것이다.
• 이런 상황에서 서버는 정상적으로 응답을 했다는 로그만 남기 때문에 애러를 찾는데 어려움이 발생한다.
• 그래서, 이런 단순 요청의 경우에는 특정 조건을 만족할 때만 요청 메세지를 보낼수 있다.

메소드는 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 옵션이다.
• same-origin(default value) :  같은 출처간의 요청에만 인증 정보를 담을수 있다.
• include : 모든 요청에 인증 정보를 담을수 있다.
• omit : 모든 요청에 인증 정보를 담을수 없다.
• 만약 credentials 옵션이 include 라면 CORS 조건 외에 2가지 조건이 추가된다.

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

---

Reference

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

https://portswigger.net/web-security/cors