CORS, 웹의 신호등

Cross-Origin Resource Sharing

교차 출처 자원 공유

---

라는 희대의 기괴한 번역...아닐까 생각이 드는 저 물건은, 서로 다른 경로로 부터 받아온 자원을 함부로 섞이지 않도록 선을 긋는 안전장치라고 할 수 있다. 실제론 안전장치 보다는 초기 프로젝트의 실행을 막는 성가신 물건 취급을 받는게 대다수인거 같다.

마치 쓰지 말라고 하면서 안쓸수가 없는 super user root 같은 존재다.

그리고 찾아보니 친절한 설명이 많았다.

https://evan-moon.github.io/2020/05/21/about-cors/

CORS는 왜 이렇게 우리를 힘들게 하는걸까?

일단 제목부터 왜 힘들게 하냐고 하고 있다. 역시 다들 성가셔하는 안전장치같다.

가볍게 내용을 요약하면,

• 이러한 정책은 CORS 와 SOP 가 있다
• SOP는 “같은 출처에서만 리소스를 공유할 수 있다”라는 규칙을 가진 정책이다
• 그러나 웹이라는 오픈스페이스 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이다
• 따라서 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 했다.
• 그 중 하나가 “CORS 정책을 지킨 리소스 요청”이다. 

각 출처는 프로토콜 + 호스트 (+ 포트번호) 로 이루어져 있고,
호스트가 달라진다면, 혹은 포트번호가 달라진다면 각기 다른 출처로 인식된다.

---

• 출처를 비교하는 로직은 서버에 구현된 스펙이 아니라 브라우저에 구현되어 있는 스펙이다.
• CORS 정책을 위반하는 요청을 하더라도 해당 서버가 같은 출처에서 보낸 요청만 받겠다는 로직을 가지고 있는 경우가 아니라면 서버는 정상적으로 응답을 한다
• 이후 브라우저가 이 응답을 분석해서 CORS 정책 위반이라고 판단되면 그 응답을 사용하지 않고 그냥 버리는 것이다.
• 즉, 브라우저를 통하지 않고 서버 간 통신을 할 때는 이 정책이 적용되지 않는다.
• 또한 CORS 정책을 위반하는 리소스 요청 때문에 에러가 발생했다고 해도 서버 쪽 로그에는 정상적으로 응답을 했다는 로그만 남는다.
• CORS가 돌아가는 방식을 정확히 모르면 에러 트레이싱에 난항을 겪을 것이다.

요청의 종류

1. Preflight Request
2. Simple Request
3. Credentialed Request

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS#%EC%A0%91%EA%B7%BC_%EC%A0%9C%EC%96%B4_%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4_%EC%98%88%EC%A0%9C

교차 출처 리소스 공유 (CORS) - HTTP | MDN

어딜 봐도 모자라지 않는 모질라 재단의 MDN 특유의 불친절한 설명을 곁들이자면, 몹시 어려워 보인다.

Access-Control-Allow-Origin : *

---

금단의 기술이니 자제하도록 하자.