WIL_CORS

CORS가 무엇인가?

이번주 WIL의 키워드가 CORS이다. 처음들어봐서 일단 GPT에게 개념을 물어봤더니 아래와 같은 답변을 받았다.

CORS는 Cross-Origin Resource Sharing의 약자로 웹 브라우저에서 실행되는 자바스크립트가 다른 도메인에서 호스팅되는 리소스에 접근하는 것을 제한하는 보안 기능이다. 기본적으로 브라우저는 같은 도메인에서 실행되는 자바스크립트 코드만이 다른 도메인에서 호스팅되는 리소스 (예를 들어 이미지, 폰트, 스크립트, API 엔드포인드 등)에 접근할 수 있다.

하지만 CORS를 허용하는 서버는 다른 도메인에서 실행되는 자바스크립트 코드도 해당 리소스에 접근할 수 있도록 허용한다. CORS를 구현하면, 서버는 HTTP 응답 헤더를 사용하여 브라우저가 해당 도메인에서 실행 중인 자바스크립트의 요청을 수락하도록 허용할 수 있다. 이것은 웹 애플리케이션에서 API를 호출하거나 다른 도메인에서 호스팅되는 리소스를 사용해야 하는 경우에 매우 유용하다.

 

CORS 에러 메세지

🚨 Access to fetch at ‘https://api.lubycon.com/me’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

 

위의 에러 메세지는 CORS 정책을 위반했을 때 만나볼 수 있다고 한다. (개발자라면 누구나 한번쯤 만나보는 에러라고 하는데 나는 본 기억이 없다....) 웹의 특성상 여기 저기서 리소스를 가져오게 되는데 CORS 정책이 있기 때문에 최소한의 안전을 보장받을 수 있는 것이다.

 

 

Origin (출처)

CORS는 우리말로 다른 출처 공유 리소스라고 할 수 있다. Cross-Origin Resource Sharing에서 Origin이 출처의 의미로 사용되는 것인데 출처는 URL에 표시되어 있다. 

 

https://redjun89.tistory.com/manage/newpost

 

위의 URL을 예로 들자면 파란부분이 프로토콜, 주황부분이 호스트이다.

그리고 생략되어있는 포트 번호까지 포함하여 서버를 찾아가기 위해 필요한 가장 기본적인 요소들을 합쳐놓은 것이

Origin (출처)인 것이다. 그래서 프로토콜, 호스트, 포트번호가 같아야 출처가 같다고 인정되는 것이다.

 

 

그렇다면 CORS는 어떻게 동작하는 것일까?

기본적으로 클라이언트가 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내게 되는데

이때 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아서 보낸다.

 

이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin이라는 값에 이 리소스를 접근하는 것이 허용된 출처를 내려주고 이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 이 응답이 유효한지 결정한다.

 

기본적인 흐름은 비교적 간단하지만 CORS가 동작하는 방식은 세 가지 시나리오에 따라 변경되므로 우리의 요청이 어떤 시나리오에 해당되는지 잘 파악하면 CORS 정책 위반으로 인한 에러에 잘 대응할 수 있다.

이번에는 여기까지만 정리하고 CORS 동작의 세가지 시나리오에 대해서는 추가로 공부하고 정리해야겠다.

 

 

 

이번주 회고

주 100시간 학습을 달성하였다.

이번주는 대부분의 시간을 주특기 주차 Lv 5 과제를 해결하는 것에 사용했다.

Lv 4의 과제를 3 계층 아키텍처 패턴에 기반하여 수정하는 것이었는데

생각보다 잘되지 않아 에러 수정하는데 많은 시간을 쏟았다.

그래도 계층형 아키텍처 패턴에 대해 기본적인 이해는 된 것 같아 뿌듯하다.

사실 기술 매니저님이 3 계층형은 아키텍처 패턴이라고 부르기도 민망한 수준이라고 하셨다.

단지 책임과 권한을 나눠준 것일 뿐이고 핵심은 그에 따른 장점과 객체 지향형 프로그래밍이 무엇인지

이해하는 것이 중요하다고 조언받았다.

 

 

다음주 목표

금요일부터 주특기 주차 토이프로젝트가 시작되었다.

처음으로 FE와 BE가 만나 시작하는 프로젝트다.

우리조는 FE가 3명, BE가 5명인 조합이다.

제출한 S.A에 대해 BE쪽은 인원에 비해 개발 스코프가 작다는 피드백이 있었다.

팀원들과 추가해볼 기능은 없는지 논의하고 적용해보면 좋을 것 같다.

내 생각엔 로그인에 Access Token과 Refresh Token 인증 방식을 적용해보면 좋을 것 같은데

제안해보고 기각되면 개인적으로 Lv5 과제에라도 적용해봐야겠다!