1. SOP(Same-Origin Policy)

- 1995년 Netscape 2.0이 공개되면서 처음으로 JavaScript가 웹 브라우저에 도입됐는데, 처음 JavaScript가 도입될 당시에는 A 웹사이트에 있는 JavaScript 코드가 B 웹사이트의 DOM element 등 여러 리소스를 임의로 조작하는 것이 가능했다. 이는 만약 악의적인 의도로 쓰인 스크립트가 있다면 심각한 보안사고로 이어질 수 있는 위험 요소였기 때문에, JavaScript의 도입 이후 얼마 지나지 않아 Netscape에 ‘JavaScript는 동일 출처의 리소스와만 상호작용할 수 있다‘라는 정책(=SOP)이 도입되게 되었다. 이는 현재 모든 브라우저들이 기본 보안 모델로 채택하게 되어, 예를 들어 현재 열람하려는 웹사이트에 있는 JavaScript 코드가 비동일 출처 리소스에 접근하는 내용을 담고 있는 경우에는 브라우저가 직접 이러한 접근을 차단한다.

  • 동일 출처: SOP를 지키려면 프로토콜, 호스트, 포트가 모두 동일해야 한다. 예를 들어, http://www.same-domain.com:3000는 오로지 http://www.same-domain.com:3000와만 동일 출처이며, http://www.cross-domain.com처럼 전혀 다른 호스트만 비동일 출처인 게 아니라 http://www.same-domain.com:8080처럼 호스트가 같아도 포트가 다르면 비동일 출처이다.

2. CORS(Cross-Origin Resource Sharing)

- 현대 모든 웹브라우저는 SOP 원칙을 엄격히 적용하고 있는데, 한편으로 현대의 많은 웹페이지는 프론트엔드단의 JavaScript 코드가 비동일 출처 백엔드 서버로부터 여러 리소스를 필요로 하는 경우가 많다. 이와 같은 경우를 고려하여 SOP 원칙이 경우에 따라 완화될 수 있어야 한다는 여론이 생겨났고, 이에 따라 과거 JSONP 같은 기술이 사용되었으나 보안 위험이 있어 새로 CORS라는 기술이 2013년 W3C 권고안으로서 공식 발표되었다.

- 구체적으로, CORS를 지원하는 브라우저는 현재 열람하려는 웹사이트에 있는 JavaScript 코드가 비동일 출처 리소스에 접근하는 내용을 담고 있는 경우에는 일단 SOP에 따라 이러한 접근을 차단하고, 다만 비동일 출처에 해당하는 제3의 호스트가 CORS 정책에 따라 비동일 출처로부터의 요청이라도 응답 메시지를 보내오는지를 검사하는 절차를 브라우저가 실행한다. 이때 만약 해당 호스트가 CORS 정책에 따라 비동일 출처로부터의 요청이라도 응답 메시지를 보내온다면, 헤더에 그에 관한 field(웹 표준에 따르면 Access-Control-Allow-Origin라는 이름의 field)에 적절한 값을 추가해 응답 메시지를 리턴한다. 이 응답 메시지를 받아 헤더로부터 해당 정보를 읽은 브라우저는 이때 SOP를 위반하는 원래 코드의 제3의 호스트 자원에 대한 접근을 허용한다.

3. XSS(Cross-Site Scripting)와 CSP(Content Security Policy)

- 90년대에 DB를 통해 웹 서비스 업체가 웹 서버를 운영하여 여러 사용자들이 여기 접속해 자신의 의견을 게시해 다른 사용자들이 널리 볼 수 있게 하는 형태의 ‘포럼’ 서비스가 유행하게 되었는데, 이에 따라 악의적인 공격자가 자신의 의견 안에 악의적인 JS 코드를 주입하여 그 코드가 그 서버에 접속한 여러 사용자들의 브라우저에서 실행되도록 하는 보안 공격이 나타나게 되었다. 이를 흔히 XSS 공격이라 하며(이 사례는 그 중에서도 Stored XSS에 해당하며 악의적 코드가 포함된 URL을 피해자들에게 배포하는 등 여러 유형의 XSS가 있다), 처음 등장한 때부터 현재까지 이를 방어하는 여러 기술이 계속 도입되고 사용되고 있다.

- XSS 공격이 대부분 피해자는 자신이 신뢰하는 웹페이지에 접속하는데 그 웹페이지에 공격자가 주입한 스크립트가 실행돼 공격자가 지정한 웹사이트로 피해자의 정보를 유출한다는 점에 주목하여, 보안성이 높은 웹서버는 애초에 서버에서 전송한 웹페이지를 클라이언트의 브라우저가 렌더링할 때 그 브라우저에게 ‘만약 내가 전송한 페이지의 코드 중에 신뢰할 수 없는 출처의 자원을 실행하는 부분이 있다면 그 부분은 실행하지 않도록 하라‘라는 지시를 HTTP 응답 메시지 헤더에 추가하기도 한다(웹 표준에 따르면 Content-Security-Policy 라는 이름의 field를 통해 한다). 서버가 클라이언트에 내리는 이와 같은 지침을 CSP라 하며, 2011년 Google Chrome의 버전 25부터 지원하기 시작해 2012년 W3C 권고안으로서 공식 발표되었다.