지난 강의에서
간단한 웹 퍼블리케이션을 통해서
처음 CORS 문제에 대해 다뤄보았습니다
CORS가 무엇인지 알아보고
Spring Security의 도움을 받아보도록 합시다
CORS는 Cross Origin Resource Sharing의 약자입니다
두 가지의 출처를 의미합니다
자신들의 자원들을 공유하려 합니다
두 출처들은 마치
우리의 클라이언트와 백엔드 애플리케이션과도 같습니다
왜 이 둘이 다른 출처라고 하는가 하면
먼저 출처가 무엇입니까?
출처는 URL입니다
URL HTTP 프로토콜과의 조합이죠
그럼 도메인, 호스트 이름은 무엇이고
웹 애플리케이션이 배포되는 포트 넘버는 무엇일까요?
이 3가지 조합들
HTTP 프로토콜
도메인과 포트가 모두 조합되어
출처라고 불리는 것입니다
서로 다른 두 애플리케이션이
소통을 하려 한다고 가정해 봅시다
그들의 출처가 당연히 다를 것입니다
포트 넘버가 다르거나
호스트 이름이 다를 것이기 때문이죠
혹은 http 프로토콜이 다를 수도 있고
아니면 전부 다 다를 수도 있습니다
서로 너무 다른 애플리케이션들이기 때문입니다
서버도 다릅니다
포트 넘버와 호스트 이름과
http 프로토콜이 같기를 기대할 수는 없습니다
그래서 이런 상황들을 교차 출처라고 하는데
간단하게 출처가 다르다는 말입니다
그들은 서로 소통하려고 합니다
그래서 이런 종류의 소통이 일어날 땐
Chrome, Firefox, Safari와 같은 최신 브라우저들은
기본적으로 이런 소통은 차단하게 되어있습니다
그 이유는 최신 과정에서의
보안적 특징 때문입니다
웹 세계에서는 아시다시피
많은 해커들이 존재하고
많은 보안 위험들이 매일 매일 생겨나고 있습니다
이러한 보안 위험들을 방지하기 위해서
최신 프로세스는
두 개의 서로 다른 출처에서 소통하는 것을
특히 특별한 설정 없이 할 경우
소통을 차단하게 되고
지난 강의에서 본
에러를 보게 됩니다
만약 유효하게 작동하는 웹 서버를
사용 중이라고 가정해봤을 때
어떤 해커가 내 서버와 그의 서버 사이의
소통을 시도한다면
그리고 CORS가 없는 상황이라면
정말 큰 보안 문제를 초래할 수 있으며
이는 웹 애플리케이션에서 수동적으로 해결해야 합니다
그러니 해커들과 수많은 보안 위험들로부터 지키기 위해
최신 브라우저들은
CORS가 기본적으로 활성화되어 있습니다
그러니 CORS는 보안 위협이 아닙니다
오히려 웹 내의 보안 위험으로부터의
보호 차원의 단계입니다
만약 누군가 CORS가 보안 공격이라고 한다면
그들에게 잘 설명해 주시기 바랍니다
그건 보안 공격이 아니라 그로부터 지키기 위해
실행되는 보호 단계일 뿐이라고 말입니다
여기까지 CORS가 무엇인지
설명해보았는데 여전히 의문이 있을 거라고 생각합니다
충분히 그럴 수 있습니다
너무나 당연합니다 그리고 이 정책이
브라우저의 완벽한 기능 중 하나라는 말에도 동의합니다
물론 여러분도 그럴 테지만 여기서 의문이 생깁니다
만약에 정말 유효한 이유로
출처가 서로 다른 애플리케이션들이 소통을
해야하는 상황에는 어떻게 해야 할까요?
Angular 애플리케이션이 Spring Boot 애플리케이션과
소통을 시도하는 것과 유사하게
기업들은 그들과 우리의 웹 애플리케이션을
다른 호스트 이름, 포트 넘버, http 프로토콜들로 지정할 수 있습니다
하지만 이를 위해서는
유효하고 정당한 사유가
뒷밤침되어야 합니다
그런 상황에서는 어떻게 브라우저에게
출처가 다른 곳에서의 소통을
허락 받을 수 있는가 하면
마찬가지로 웹 애플리케이션 내에서
CORS 문제를 다루기 위해
사용 가능한 해결책들을 다음 강의에서 배워보겠습니다
감사합니다 다음 강의 때 뵙겠습니다
수고하셨습니다