요약

  • W3C의 Subresource Integrity 첫 공개 초안은 2014년 3월 18일 나왔다. 가져온 자원을 암호학적 해시로 확인하는 방식을 제안했으며, 검토한 HTML 요소의 범위는 2016년 권고안보다 넓었다.
  • 2016년 6월 23일 W3C 권고안은 스크립트와 스타일시트 링크에 integrity 속성을 정했다. 브라우저는 확인할 수 있는 응답의 해시를 기대값과 비교하고 다르면 실행이나 표시를 거부한다.

배달원은 늘 가던 주소로 찾아왔다. URL도 같고 파일 이름도 익숙했다. 하지만 상자 안까지 어제와 같으리라는 보장은 없다. JavaScript 내용이 바뀌면 페이지의 행동이 달라질 수 있고, 스타일시트가 바뀌면 독자가 보는 모양이 달라질 수 있다. URL은 어디에서 가져올지 알려 준다. 해시는 페이지가 어떤 판본을 주문했는지 알려 준다.

W3C가 2014년 3월 18일 공개한 첫 작업 초안은 가져온 자원을 암호학적 해시와 비교하는 구상을 제시했다. 처음에는 스크립트와 스타일뿐 아니라 이미지와 프레임까지 여러 요소를 후보로 올렸다. 작업대 위에 도구가 가득했던 시절이다. 뒤의 문서들은 실제로 적용할 자리를 더 좁고 분명하게 정했다.

2015년 11월 12일 후보 권고안 스냅샷에서 integrity 속성은 script와 스타일시트를 가리키는 link에 집중됐다. 2016년 6월 23일 W3C 권고안도 그 두 문을 택했다. 작성자는 HTML의 자원 URL 옆에 기대하는 해시 정보를 놓는다. 브라우저는 파일을 가져와 검사할 수 있는 응답의 해시를 계산한 뒤 두 값을 비교한다. 주소를 확인한 다음에는 상자 속 물건도 확인하는 셈이다.

메타데이터에는 해시 함수의 이름과 예상 결과가 들어간다. 2016년 권고안은 사용자 에이전트가 SHA-256, SHA-384, SHA-512를 지원하도록 했다. 한 자원에 여러 값을 적을 수도 있으며, 지원되는 해시 함수 중 가장 강한 것을 우선한다. 외부 파일이 코드를 실행하거나 화면 모양을 바꾸기 직전에, 페이지가 기대한 판본을 명확히 말할 수 있게 됐다.

검사하려면 응답 내용을 읽을 수 있어야 한다. 같은 출처의 응답은 확인할 수 있고, 다른 출처의 응답도 CORS가 읽기를 허용하면 확인할 수 있다. 불투명한 응답에서는 비교할 바이트를 볼 수 없다. 따라서 작성자는 맞는 해시를 준비하는 동시에 브라우저가 실제 파일을 검사할 수 있는 전달 방식도 마련해야 했다. 대조는 브라우저의 가져오기 규칙 안에서 돌아간다.

값이 일치하지 않으면 2016년 권고안은 브라우저가 자원의 실행이나 표시를 거부하고 네트워크 오류로 다루도록 한다. 오류 이벤트를 받은 작성자는 자신이 알고 있는 예비 파일을 제공할 수 있다. 단골 배달원도 주문과 다른 상자를 가져오면 문 앞에서 멈춘다. 독자의 작업을 어떻게 이어 갈지는 사이트가 준비할 몫이다.

W3C 발행 이력은 2014년 첫 공개 초안에서 2015년 후보 단계와 2016년 권고안까지의 경로를 보여 준다. 2016년 6월 23일 W3C 발표는 가져온 자원이 예상 밖의 변경 없이 도착했는지 확인하는 기법이라고 설명했다. 그 경로에는 대상 범위가 넓은 초기 목록에서 스크립트와 스타일시트 링크로 좁혀지는 과정도 보인다.

편집자의 일상 업무에도 규칙이 생겼다. 의도적으로 파일을 업데이트한다면 예상 해시도 함께 바꿔야 한다. 낡은 값은 원치 않는 교체뿐 아니라 정당한 새 버전도 막는다. 작성자가 주문서를 쓰고 브라우저가 배달품을 잰다. URL은 배달원을 현관까지 데려온다. 지문은 상자 안에 주문한 물건이 있는지 답한다.