whenever purple

항해99 5주차에는 프론트엔드와 백엔드가 함께 미니프로젝트를 진행하게 되었다.

그전에도 CORS 모듈을 설치에 진행하는 것이 좋다라고만 들었는데, 

프론트 작업과 연결시 필요한 작업이기에 CORS를 자세히 알아보기로 했다.

CORS란?

CORS(Cross-Origin Resource Sharing), 교차 출처 리소스 공유라고 해석된다. 
CORS정책은 우리가 가져오는 리소스들이 안전한지 검사하는 관문이다. 

웹 개발을 하다보면 CORS 정책 위반으로 인해 에러가 발생한다. 콘솔에서 아래와 같은 메세지를 확인할수 있다.

CORS 관련 이슈는 모두 CORS 정책을 위반했기 때문에 발생한다.

위의 에러는 CORS를 허용해서 아무런 탈 없이 다른 출처 리소스를 공유해달라는 권고사항과 같은 것이다.

CORS라는 방어막 덕분에 우리가 이 곳 저 곳에서 가져오는 리소스가 안전하다는 최소한의 보장을 받을 수 있다.

출처 (Origin) 란?

서버의 위치를 의미하는 URL은 Protocol, Host, Port 까지를 의미한다. 

웹에는 SOP(Same Origin Policy) 와 CORS(Cross Origin Resource Sharing) 두가지 정책이 있다.

▶ SOP(동일 출처 정책) ◀

같은 출처에서만 리소스를 공유할 수 있다" 라는 규칙을 가진 정책

→ URL의 구성요소 중 Protocol, Host, Port 세가지 동일한지 확인한다.

→ 같은 Protocol, Host, Port을 사용한다면 요소는 다르더라도 같은 출처로 인정된다.

→ 리소스가 자신의 출처와 다를경우, 브라우저는 교차출처 요청을 실행한다. 

즉, Protocol, Host, Port 중 하나라도 일치하지 않으면 Cross Origin 이라고 한다. 

▷ 실무에서 참고하자면 ◁

프론트 서버와 백엔드 서버 연결시

프론트 서버 URL이  http://localhost:3000,

백엔드 서버 http://localhost:8080 일때

SOP 정책에 어긋나기때문에, 서버로부터 응답이 넘어올 때 

브라우저에서 CORS 정책 오류를 발생시킨다. 

▶ CORS (교차 출처 리소스 공유) ◀

추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의

선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게  알려주는 체제이다. 

CORS 동작방식

1. 클라이언트에서  HTTP요청 헤더에 Origin을 담아 전달한다. 

2. 서버는 응답헤어에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.

3. 클라이언트에서 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다. 

자신이 보낸 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교하여 차단할지 말지 결정한다. 

만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. 

(위의 경우 둘다 http://localhost:3000 이기 때문에 유효한 경우다.)

아래의 블로그를 참고하여 작성되었습니다.

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F