[Network] SOP

SOP (Same Origin Policy)

SOP 란 동일 출처 정책이란 뜻으로 동일한 출처의 리소스만 상호작용을 허용하는 정책이다. A 출처에서 온 문서가 B 출처에서 가져온 리소스와 상호작용하는 것을 차단하는 보안 정책이다. 두 URL의 프로토콜, 호스트, 포트가 모두 같아야 동일한 출처로 인정되며 웹 사이트를 샌드박스화 하여 잠재적 보안 위협으로 부터 보호하는 정책이다.

 

개발 시에 해당 문제로 인해 자주 귀찮음도 겪고 불편한 점이 이만저만이 아니다. 그런데 왜 굳이 SOP 가 등장했을까? 다른 출처 간의 상호작용을 차단하지 않는다면 어떤일이 발생하게 되는지 살펴보자.

 

SOP가 없는 상황에서 악의적인 JavaScript가 포함된 페이지에 접속하는 상황을 가정해보자. 사용자가 악성페이지에 접속하여 악의적인 JavaScript가 실행되면 사용자가 모르는 사이에 포털사이트인 'potal.example.com'으로 임의의 요청을 보내고 그 응답값을 해커의 서버로 보내 사용자의 정보가 탈취될 것이다. 더 나아가 JavaScript를 사용해 사용자가 접속중인 내부망의 아이피와 포트를 스캐닝하거나 해커가 사용자 브라우저를 프록시처럼 사용할 수도 있다. 이러한 경우가 발생할 가능성을 사전에 방지하기 위해 SOP가 존재한다고 할 수 있다.

Cors(Cross-Origin Resource Sharing) 정책이란?

보안도 중요하지만 개발 중에는 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야하는 케이스가 존재한다. 이런 경우를 대비하기 위해 SOP의 예외 정책으로 Cross-Origin Resource Sharing 정책을 마련했다. 따라서 CORS를 이용하면 SOP의 제약을 받지 않는다.

 

클라이언트는 HTTP 패킷에 자신의 프로토콜, 호스트, 포트 정보를 Origin 헤더에 담아 전송하고 서버에서는 Origin 헤더를 보고 어느 사이트로부터 요청이 됐는지 확인할 수 있다. 서버는 다른 출처와의 상호작용을 Access-Control-Allow-Origin 헤더를 통해 이를 설정한다. 해당 헤더에 상호작용을 하고자 하는 도메인을 명시하면 된다.

Preflight

미리 보내는 것, 사전 전달이라고 생각하면 된다. 기본적으로 브라우저는 cross-origin 요청을 전송하기 전에 OPTIONS 메소드로 preflight를 전송한다. 이때 Response로 Access-Control-Allow-Origin과 Access-Control-Allow-Methods 가 넘어오는데 이는 서버에서 어떤 origin, method를 허용하는지 브라우저에게 알려주는 역할을 한다. 브라우저가 결과를 성공적으로 확인하고 나면 cross-origin 요청을 보내 그 이후 과정을 진행한다.

 

cross-origin 요청을 보낼때마다 preflight를 보내지는 않는다. 서버 설정을 통해 preflight 결과의 캐시를 일정 기간 동안 저장시킬 수 있다. 이 캐시 정보가 살아있는 동안은 cross-origin 요청에 대해 preflight를 생략하고 바로 요청 전송이 가능하다.