CS Visualized: ✋🏼🔥 CORS

reference: https://dev.to/lydiahallie/cs-visualized-cors-5b8h

모든 개발자들이 한 번쯤은 콘솔에서 빨간색 에러인 Access to fecthed has been blocked by CORS policy를 보고 답답함을 가졌을 거예요! 😬 이 에러를 빠르게 제거할 수 있는 몇 가지 방법이 있지만 그런 기본적인 것들을 하는 대신, CORS가 실제로 하는 것이 무엇이고 실제로는 그것이 왜 우리에게 도움이 되는지 알아보도록 하죠 👏🏼

❗️ 이번 포스트에서는 HTTP의 기본에 대해서는 설명하지 않습니다. 혹시 여러분들이 HTTP 요청과 응답에 대해 더 알고 싶으시다면, 제가 얼마 전에 간단하게 작성한 게시물을 봐주세요. 🙂 이번 예시는 HTTP/2가 아닌 HTTP/1.1로 작성되었지만 CORS와는 무관합니다.

프론트엔드에서는 종종 다른 곳에 위치한 데이터를 표시해야할 때가 있죠! 이런 데이터를 표시하기 전에, 브라우저는 먼저 해당 데이터를 가져오기 위해 서버에 요청을 해야합니다! 클라이언트는 서버가 클라이언트에게 다시 데이터를 돌려주기 위해 필요한 모든 정보들을 HTTP 요청에 실어 보냅니다. 🙂

api.website.com이 위치한 서버에서 www.mywebsite.com 웹 사이트의 사용자 정보를 가져오려고 한다고 해보죠!

완벽합니다! 😃 방금 HTTP 요청을 서버로 보낸 뒤, 우리 요청한 JSON 데이터를 응답받았습니다.

이제 정확히 똑같은 요청을 다른 도메인에서 실행하다고 해보죠. www.mywebsite.com에서 요청을 만드는 대신, 이제 www.anotherdomain.com에서 요청을 만들어보겠습니다.

잠깐, 뭐죠? 우린 완전히 동일한 요청을 보냈는데 이번에는 브라우저가 이상한 에러를 보여주네요? 우린 방금 CORS를 실제로 본 것입니다 💪🏼 이제 왜 이 에러가 발생했는지 그리고 이것이 의미하는 바가 무엇인지 알아보도록 하겠습니다.

✋🏼 동일 출처 정책(Same-Origin Policy)

웹은 동일 출처 정책(same-origin policy)라는 것을 시행하고 있습니다. 기본적으로, 우리는 요청과 동일한 출처에 위치한 리소스만 접근이 가능합니다! 💪🏼

예를 들어, https://mywebsite.com/image1.png에 위치한 이미지를 로드하는 건 괜찮다는거죠.

리소스가 다른 (서브)도메인, 프로토콜 또는 포트에 위치한 경우를 교차 출처(cross-origin)이라고 합니다!

멋있어보이지만, 동일 출처 정책이 존재하는 이유는 무엇일까요?

동일 출처 정책이 없고, 여러분들의 이모가 Facebook에서 보낸 많은 바이러스 링크 중 하나를 클릭했다고 해보죠. 이 링크는 여러분들의 은행 웹 사이트가 iframe으로 로드되는 악의적인 웹 사이트로 리다이렉션하게 되고, 일부 쿠키를 사용해서 로그인을 성공적으로 수행하게 되겠죠! 😬

이런 악의적인 웹 사이트의 개발자들은 웹 사이트가 여러분들을 대신하여 자신의 계좌로 돈을 보내도록 하기 위해 iframe으로 은행 웹 사이트의 DOM 컨텐츠와 상호작용을 할 수 있게 할거예요!

네..엄청난 보안 리스크죠! 우린 누구도 모든 것에 접근할 수 있기를 원하지 않아요 😧

다행스럽게도, 동일 출처 정책이 우리를 도와줍니다! 이 정책은 같은 출처에서만 리소스에 접근할 수 있도록 확인해줍니다.

이번에는 www.evilwebsite.com이란 출처가 www.bank.com의 교차 출처 자원에 접근하려고 합니다! 동일 출처 정책이 이런 요청을 막아주고 악의적인 웹 사이트의 개발자가 우리의 은행 데이터에 접근할 수 없도록 보장해줍니다 🥳

좋아요, 근데 이것이 CORS와 무슨 관계가 있는걸까요?

🔥 클라이언트 영역의 교차 출처 리소스 공유(Client-side CORS)

동일 출처 정책이 실제로는 스크립트에만 적용되지만 브라우저는 이 정책을 JavaScript의 요청까지 “확장”합니다: 기본적으로 동일한 출처에서 가져온 리소스에만 접근할 수 있습니다!

흠, 그런데…우린 종종 교차 출처의 자원들에 접근해야 할 때가 있죠 🤔 데이터를 로드하기 위해 프론트엔드가 백엔드 API와 상호작용을 할 때가 있다면요? 교차 출처 요청을 안전하게 처리하기 위해 브라우저는 CORS라고 하는 매커니즘을 사용합니다! 🥳

CORS는 교차 출처 리소스 공유(Cross-Origin Resource Sharing)의 약자입니다. 브라우저가 동일한 출처에 위치하지 않은 리소스에 접근을 허락하지 않더라도, 우리는 CORS를 통해 해당 보안적 제약을 약간 변경하여 해당 리소스에 안전하게 접근할 수 있습니다 🎉

사용자 에이전트 (예: 브라우저)는 CORS 매커니즘을 사용하여 HTTP 응답의 특정한 CORS 관련 헤더 값을 기반으로 차단된 교차 출처 요청을 허용할 수 있습니다! ✅

교차 출처 요청이 이루어지면, 클라이언트는 자동적으로 추가 헤더를 HTTP 요청에 덧붙입니다: Origin이죠. Origin 헤더의 값은 요청을 어디에서 하는지를 나타내는 출처입니다!

브라우저가 교차 출처의 자원에 접근이 가능하도록 하기 위해, 서버 응답에서 교차 출처 요청을 허용하는지에 대한 여부를 나타내는 특정 헤더가 넘어오길 기다립니다!

💻 서버 영역의 교차 출처 리소스 공유(Server-side CORS)

서버 개발자는 Access-Control-* 로 시작하는 것들을 HTTP 응답에 추가 헤더를 덧붙여 주어 교차 출처 요청을 허락할 수 있게 됩니다. 🔥 이러한 CORS 응답 헤더의 값을 기반으로 브라우저는 이제 동일 출처 정책에 의해 차단된 교차 출처 응답 중 특정한 것들을 허용할 수 있게 됩니다!

우리가 사용할 수 있는 몇 가지의 CORS 헤더들이 있지만, 교차 출처 리소스의 접근을 허용하기 위해 브라우저에 필요한 헤더가 하나 있습니다: Access-Control-Allow-Origin이죠! 🙂 이 헤더의 값은 브라우저가 서버에게 요청한 리소스에 접근할 수 있는 출처를 지정해줍니다.

만약 서버가 https://mywebsite.com에서 접근할 수 있는 서버를 개발하는 경우, Access-Control-Allow-Origin 헤더의 값을 해당 도메인으로 추가해주면 됩니다!

놀랍네요! 🎉 이 헤더는 이제 서버가 클라이언트로 돌려주는 응답에 추가됩니다. 이 헤더가 더해짐으로써, 만약 우리가 https://mywebsite.com에서 https://api.mywebsite.com 에 위치한 리소스를 요청하고 받는데 더 이상 동일 출처 정책이 제한을 걸지 않습니다!

브라우저 내의 CORS 매커니즘은 Access-Control-Allow-Origin헤더의 값이 요청에 의해 보내진 Origin의 값과 같은지를 확인하는 것이죠. 🤚🏼

이번 경우, 요청의 출처는 https://www.mywebsite.com 이고, 이건 Access-Control-Allow-Origin 응답 헤더의 목록에 속해있죠!

완벽하네요! 🎉 우린 교차 출처 리소스를 성공적으로 수신할 수 있게 되었어요! 그럼 Access-Control-Allow-Origin 헤더의 목록에 속하지 않은 출처의 자원에 접근하려 한다면 어떤 일이 일어날까요? 🤔

아아 네, CORS는 때때로 우리를 답답하게 하는 이 악명 높은 에러를 던지죠! 하지만 이제 우린 이걸 완전히 이해할 수 있죠.

The 'Access-Control-Allow-Origin' header has a value
 'https://www.mywebsite.com' that is not equal 
to the supplied origin.

이번 경우, 제공된 출처는 https://www.anotherwebsite.com이죠. 하지만 서버는 Access-Control-Allow-Origin 헤더 내 허용된 출처의 목록에 이 출처가 없죠! CORS는 이 요청을 성공적으로 차단하고, 코드 내에서도 가져온 데이터에 접근할 수 없게 되죠 😃

CORS 또한 허용된 출처의 값으로 *인 와일드카드를 추가할 수 있게 해줍니다. 이 말은 모든 출처에서 요청한 리소스에 접근할 수 있다는 것이니 주의가 필요합니다!

Access-Control-Allow-Origin은 우리가 제공할 수 있는 많은 CORS 헤더 중 하나입니다. 서버 개발자는 서버의 특정 요청을 허용하지 않기 위해 COS 정책을 확장할 수 있습니다! 💪🏼

보통 사용되는 또 다른 헤더는 Access-Control-Allow-Methods 헤더입니다! CORS는 지정된 메서드로 전송이된 경우에만 교차 출처 요청을 허용하게 될 겁니다.

이번에는, GET, POST 또는 PUT 메서드로 오는 요청만 허락됩니다! 다른 PATCH나 DELETE같은 다른 메서드들은 차단됩니다 ❌

만약 다른 사용 가능한 CORS 헤더들이 무엇인지 궁금하고, 어디에 사용되는지 궁금하다면, 이 목록을 확인해보세요.

PUT, PATCH 및 DELETE 요청에 대해 CORS는 실제로 이 요청들을 다르게 처리합니다! 🙃 이런 ”단순하지 않은” 요청은 사전 요청(preflight request)라고 부를께요!

🚀 사전 요청(Preflighted Requests)

CORS는 요청을 두 가지로 구분합니다: 단순 요청과 사전 요청이죠. 단순한지 전처리가 필요한지에 대한 여부는 요청 내의 일부 값에 따라 달라집니다(걱정 말아요. 이것들을 기억할 필요는 없어요).

요청이 GET 또는 POST 메서드고 사용자 지정 헤더가 없을 경우 이 요청은 단순 요청입니다! PUT, PATCH 또는 DELETE 메서드로 이뤄진 요청 같은 경우는 전처리 됩니다.

만약 단순 요청을 만들기 위해 어떤 요구 사항이 충족되어야 하는지 궁금하다면 MDN에 유용한 리스트가 있습니다!

그런데 “사전 요청”이란 무엇이고, 왜 이런 게 생겼을까요?

실제 요청이 전송되기 전에, 클라이언트는 사전 요청을 생성합니다! 사전 요청에는 Access-Control-Request-* 헤더에 실제 요청 하려고 하는 정보가 포함되어 있습니다 🔥

이것은 브라우저가 하고자 하는 실제 요청에 대한 서버의 정보가 제공됩니다: 요청의 메서드, 추가적인 헤더들 그리고 기타.

서버는 이 사전 요청을 수신하고 빈 HTTP 응답을 서버의 CORS 헤더들을 실어 보냅니다! 브라우저는 빈 데이터와 CORS 헤더들이 있는 사전 응답을 수신하고 허용되는 HTTP 요청이 무엇인지 확인합니다! ✅

이 경우, 브라우저는 실제 요청을 서버로 보내고, 요청한 데이터가 있는 응답을 수신하게 됩니다!

하지만 그렇지 않은 경우 CORS는 사전 요청을 차단하고, 실제 요청은 전송되지 않습니다. ✋🏼 사전 요청은 CORS 정책이 (아직) 사용가능하지 않은 서버의 리소스에 접근하거나 수정하는 것을 막는 좋은 방법입니다! 서버는 이제 잠재적으로 원하지 않는 교차 출처 요청으로부터 보호됩니다 😃

💡 서버와의 왕복 횟수를 줄이기 위해 CORS 요청에 Access-Control-Max-Age 헤더를 추가하여 사전 응답을 캐시할 수 있습니다! 사전 응답을 이런식으로 캐시하게 되면, 브라우저는 새로운 사전 요청을 보내는 대신 이것을 사용합니다!

🍪 자격 증명(Credentials)

쿠키, 인증 헤더 및 TLS 인증서는 기본적으로 동일 출처 요청에서만 설정이 됩니다! 하지만, 이러한 자격 증명들을 교차 출처 요청에서도 사용해야 할 때가 있죠. 서버가 사용자를 식별하기 위해 쿠키를 요청에 포함시키고 싶을 수가 있어요!

CORS가 기본적으로 자격 증명을 포함하지 않지만, 우린 Access-Control-Allow-Credentials CORS 헤더를 추가하여 이를 바꿀 수 있습니다! 🎉

만약 교차 출처 요청에 쿠키 및 다른 권한 헤더를 포함하려면, 요청에서 withCredentials 필드에 true를 할당하고 Access-Control-Allow-Credentials 헤더를 응답에 추가해야 합니다.

설정이 다 됐습니다! 이제 교차 출처 요청에 자격 증명을 포함할 수 있습니다 🥳

CORS 에러가 때때로 답답하다는데 모두 동의 할거라고 생각하지만, 브라우저에서 교차 출처 요청을 안전하게 만들 수 있따는 것은 놀라운 일입니다 (분명 사랑을 받아야 하는 기능이예요) ✨

당연히 이 포스트에서 다룰 수 있는 것보다 훨씬 더 많은 동일 출처 정책과 CORS가 존재합니다. 다행히도, 이것들에 대해 더 많은 정보들이 여기나 W3 스펙에 많이 있습니다! 💪🏼

늘 그렇듯, 질문은 환영입니다! 😊