CORS 이해하기

CORS의 존재 이유를 알고 나면 나머지는 이해하기 쉽다.

2019. 7. 17

CORS의 쓸모란 무엇일까

브라우저는 서버 A와 협동해서 서버 A의 사용자들을 지켜준다.

웹 페이지: 저는 B에서 온 웹 페이지인데 서버 A에 데이터를 좀 요청하고 싶어요.
브라우저: 잠깐 A한테 물어보고 올게요.
       (서버 A에게) B에서 온 애가 말을 좀 걸고 싶다는데 괜찮을까요?

웹페이지(서버 B가 제공)에서 스크립트로 서버 A의 데이터를 가져오려고 하면 브라우저는 미리 OPTIONS 메서드로 서버에게 이런 요청이 가능한 건지 물어본다. 서버 A 는 괜찮은지 아닌지 대답해준다.

서버 A가 CORS를 구현했으면 브라우저에게 명확한 동의,

브라우저: (서버 A에게) B에서 온 애가 말을 좀 걸고 싶다는데 괜찮을까요?
서버 A: 네, 괜찮습니다.
브라우저: (B에서 온 웹페이지에게) 가능하답니다.

혹은 거절의 의사를 밝혀줄 것이다.

브라우저: (서버 A에게) B에서 온 애가 말을 좀 걸고 싶다는데 괜찮을까요?
서버 A: 아니요, 안됩니다.
브라우저: (B에서 온 웹페이지에게) 안 된답니다.

만약 서버가 CORS를 구현하지 않았다면 아무렇게나 응답할 것이다.

브라우저: (서버 A에게) B에서 온 애가 말을 좀 걸고 싶다는데 괜찮을까요?
서버 A: 서버 A에 오신 겻을 환영합니다. (CORS를 구현 안함)
브라우저: (B에서 온 웹페이지에게) 안 된답니다.

브라우저는 서버 A가 명확하게 동의해주지 않는 한 다른 서버가 준 웹 페이지에서 서버 A로 요청을 보내주지 않는다.

보통 CORS는 SPA에서 클라이언트 웹과 서버의 주소(명확하게는 출처, origin)이 다르기 때문에 겪는 경우가 많다.

브라우저가 우리 클라이언트 앱을 막는 게 아니라, 사실은 우리 API 서버를 지켜주려고 하는 거라고 생각하면 마음이 편안해진다.

CORS 프로토콜 정의는 Fetch 명세의 하위 섹션이다.

의도하지 않은 다른 웹페이지가 우리 서버에게 말을 못 걸도록 지켜주려는 브라우저에게,

의사를 전달하는 프로토콜이다.

그러므로 브라우저 외의 HTTP 클라이언트(curl 등)는 CORS를 지키지 않는다. 위의 예시에서 등장한 ‘B에서 온 웹 페이지’에는 때 B라는 출처(origin)가 있지만 비 브라우저 클라이언트들에게는 출처 개념이 없기 때문에 애초에 CORS가 성립하지 않는다.