요약

  • 2009년 1월 Origin 초안은 HTTP 요청을 일으킨 브라우저의 보안 맥락을 서버에 알리는 헤더를 제안했다. 2011년 12월의 RFC 6454는 그 밑바탕인 ‘어떤 페이지들이 같은 출처인가’라는 규칙을 정리했다.
  • 브라우저는 방식, 호스트, 포트를 비교한다. 경로는 비교하지 않는다. 같은 출처에서 실행 가능한 HTML로 배포된 외부 기고문은 사이트의 다른 페이지와 브라우저 권한을 나눌 수 있다.

폴더 두 개, 출입증 하나

서비스가 계정 화면을 /account에, 방문자 글을 /uploads에 둔다. 서버 관리자 눈에는 다른 폴더다. 브라우저는 주소의 앞부분부터 본다. 방식과 호스트, 포트가 같으면 같은 출처다. 슬래시 뒤에 붙은 이름은 출입증에 적히지 않는다.

2011년 12월에 나온 RFC 6454는 브라우저에서 이미 자라난 동일 출처 정책에 정확한 자를 대었다. 웹 애플리케이션은 페이지와 파일을 여럿 쓴다. URL 하나마다 서로 모르는 손님처럼 취급했다면 매번 허락을 받아야 했을 것이다. 출처는 그 자원을 한 묶음으로 움직이게 한다. 대신 묶음 안에 무엇을 넣을지는 운영자의 책임이 된다.

RFC의 주소 예시는 분명하다. example.com의 HTTP 페이지와 같은 호스트에서 포트 80을 명시한 다른 경로는 같은 출처다. 80이 HTTP의 기본 포트이기 때문이다. 포트를 바꾸면 다른 출처가 된다. 같은 호스트라도 HTTP에서 HTTPS로 옮기면 달라진다. 보호받지 않은 연결에서 온 페이지가 HTTPS 페이지의 브라우저 신뢰를 그대로 가져가서는 안 된다는 판단이 여기 들어 있다. 반면 /account와 /uploads는 세 요소가 같으면 같은 묶음에 남는다.

남의 HTML도 같은 방에 들어왔다

사용자가 보낸 파일을 사이트의 주 출처에서 실행 가능한 HTML로 제공하면, 그 안의 스크립트는 그 출처의 브라우저 권한으로 움직일 수 있다. RFC는 사용자 콘텐츠를 다루며 응답의 미디어 유형을 따져야 한다고 짚는다. 서버가 계정 작업마다 별도의 권한 검사를 하는 일과는 층위가 다르다. 브라우저는 /uploads라는 폴더 이름을 보고 페이지의 지위를 낮추지 않는다.

2009년 1월의 Origin 초안은 서버에 도착한 요청에서 이야기를 시작했다. 제안된 Origin 헤더는 요청을 낳은 보안 맥락을 밝히고, 서버가 다른 사이트에서 보낸 위조 요청을 살피는 데 쓸 수 있었다. 그 문서는 채택된 표준이 아닌 Internet-Draft였다. RFC 6454는 요청을 보내기 전부터 브라우저가 페이지를 분류하는 출처 개념을 정리하고, 그 출처를 요청에 적는 방법도 정의했다. 일반적인 세 요소가 없는 출처는 null로 표시된다. 사생활에 민감한 맥락의 요청에도 같은 값을 쓰도록 했다.

뒤이어 2014년 W3C CORS 권고안은 출처를 이용해 다른 사이트가 응답을 읽을 수 있는지 결정했다. 권고안은 응답을 읽게 하는 일과 요청이 일으키는 동작을 허가하는 일을 구분했다. 그 초대장보다 먼저 브라우저는 같은 방에 들어온 페이지의 명단을 만들었다.

RFC 6454는 그 명단을 만드는 규칙을 적었다. 포트는 세고, 경로는 세지 않는다. 누가 방에 들어오는지는 사이트가 실제로 무엇을 어떻게 내보내는지에 달렸다.