요약

  • 2007년 2월 W3C 초안은 자원 소유자가 다른 사이트에 읽기를 허용하는 방식을 탐색했다. 2009년 3월 CORS 초안에는 요청 페이지의 Origin, 자원 측의 허가 응답, 브라우저의 확인 절차가 더 뚜렷해졌다.
  • 2014년 1월 권고안은 Access-Control-Allow-Origin을 통한 읽기 판단을 기술했다. 특정 메서드나 헤더에는 OPTIONS 사전 요청이 필요하지만, 단순한 요청은 서버에 닿고도 페이지의 프로그램에는 응답이 보이지 않을 수 있다.

날씨 그래프를 그리는 페이지가 다른 사이트의 관측값을 원한다. 컴퓨터는 주소를 알고 서버까지 갈 수 있다. 그래도 브라우저는 낯선 집에서 온 답장을 아무 페이지의 프로그램에나 펼쳐 보이지 않는다. 동일 출처의 경계가 지키는 것 가운데 하나가 바로 이 읽기 권한이다. CORS는 자원 주인이 직접 예외를 써 주고 브라우저가 확인하도록 만든 방식이었다.

2007년 2월 15일 W3C 초안 Enabling Read Access for Web Resources는 HTTP 헤더나 XML 처리 명령으로 다른 사이트의 읽기를 허락하는 길을 제안했다. 어떤 호스트를 어떻게 지정할지는 여전히 실험 중이었다. 완성된 CORS는 아니었지만 핵심은 분명했다. 허락은 자료를 내놓는 쪽에서 나온다. 2009년 3월 17일 CORS 작업 초안은 요청의 Origin과 응답의 허가 헤더를 연결하고 브라우저가 두 값을 살피는 절차를 더 구체화했다.

2014년 1월 16일 W3C 권고안에서 자원은 Access-Control-Allow-Origin으로 읽기를 허락할 출처를 밝힌다. 브라우저는 이를 요청한 페이지의 출처와 대조한 다음 프로그램에 응답을 건넨다. 자격 증명을 보내지 않는 공개 자원이라면 *로 넓게 열 수도 있다. 자격 증명을 포함한 요청에는 일치하는 구체적인 출처와 Access-Control-Allow-Credentials: true가 필요하다. 누구나 들르라는 안내문과 이름이 적힌 초대장은 서로 다르다.

어떤 손님은 먼저 노크해야 한다. 프로그램이 단순한 범위를 벗어나는 메서드나 직접 정한 헤더를 사용하면 브라우저는 OPTIONS 사전 요청으로 서버가 허용하는 메서드와 헤더를 묻는다. 답을 확인한 뒤 본 요청을 진행하고, 그 결과를 잠시 저장할 수도 있다. 그러나 모든 교차 출처 요청 앞에 이런 절차가 있는 것은 아니다. 초인종이 울리지 않았다고 고장부터 의심할 일은 없다.

가장 중요한 차이는 요청의 도착과 응답의 공개 사이에 있다. 단순한 요청은 서버에 도착해 처리될 수 있지만 브라우저는 답장을 페이지의 프로그램에 보여 주지 않을 수 있다. 2014년 권고안의 보안 논의는 요청과 그 부작용을 허용하는 일, 돌아온 표현을 읽도록 허용하는 일을 명확히 구분한다. 계좌를 바꾸거나 돈을 보내는 요청의 권한은 서버가 직접 판단해야 한다. CORS 헤더는 답장 배달 규칙이지 금고 열쇠가 아니다.

W3C의 CORS 발행 이력에는 2007년 초안, 2014년 권고안 발표, 그 문서의 2020년 공식 폐기가 이어진다. 그 역사에서 해결한 문제는 선명하다. 자원 주인은 자기 응답을 읽을 다른 출처를 정하고, 브라우저는 그 결정을 집행한다. 그래프에는 숫자가 들어오지만 옆집 열쇠꾸러미까지 넘어오지는 않는다.