✏️ STOMP를 활용한 실시간 양방향 채팅 프로그램을 구현하던 중 만난 CORS에 대해 알아보고자 한다.
Same-Origin Policy
동일한 출처에 대한 정책이며, '동일한 출처에서만 리소스를 공유할 수 있다'는 법률을 가진다.
즉, 동일 출처 서버에 있는 리소스는 자유롭게 가져올 수 있지만, 다른 출처에 있는 서버에 있는 리소스는 상호작용할 수 없다.
다른 출처에 있는 서버를 자유롭게 사용하게 될 경우, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 해킹할 수 있다.
따라서 동일 출처 서버에 있는 리소스만 사용을 가능하게 함으로써 보안을 높인다.
Cross-Origin Resource Sharing
교차 출처 리소스 공유 정책이며, 여기서 교차 출처는 (엇갈린)다른 출처를 의미한다.
추가 HTTP 헤더를 사용해 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처(프로토콜, 도메인, 포트 번호)의 리소스에 접근할 수 있는 권한을 부여하도록 브라우저에서 알려주는 체제이다.
도메인, 프토로콜, 포트 번호 중 하나라도 다를 경우 CORS라고 판단되어 CORS HTTP 요청을 제한한다. 권한을 부여받기 위한 CORS 요청은 서버에서 허가를 받아야 하는데, HTTP-Header를 통해 받을 수 있다.
즉, 도메인, 프로토콜, 포트가 모두 일치하면 Same-Origin이며, 하나라도 일치하지 않는다면 Cross-Origin이다.
기본적인 흐름은 다음과 같다.
1. 먼저, 웹 애플리케이션이 다른 출처의 리소스에 접근할 때 HTTP Header에 요청을 보낸다.
2. HTTP 프로토콜을 사용해 요청을 보내며, 요청 헤더에 'Origin 필드 : {요청을 보내는 출처}'를 담아 보낸다.
3. 이후, 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 'Acess-Control-Allow-Origin'에 4. '리소스 접근이 허용된 출처'를 내려주고, 응답을 받은 브라우저는 자신이 보낸 Origin과 서버가 보내준 응답인 'Access-Control-Allow-Origin'을 비교해 유효한 응답인지 확인한다. 유효하지 않으면 그 응답을 사용하지 않는다.
추가로 세 가지 시나리오에 의해 변경되기도 하는데, 아래 블로그 글을 참고하길 바란다.
다음 글에는 STOMP를 구현하는 과정에서 CORS가 발생한 이유와 해결 방법에 대해 적어볼 것이다.
