Summary

  • 10월 27일 나온 CDNI 작업반 초안 -13판은 허용된 Origin에 발급한 Access-Control-Allow-Origin: * 응답이 공유 캐시에서 잘못 재사용되면 제외된 출처에도 도착할 수 있다고 설명한다.
  • 초안은 CORS의 판단 위치도 분명히 한다. 하위 CDN은 공개 자원을 제공하고, 규칙을 따르는 브라우저가 그 응답을 다른 출처의 스크립트에 보여 줄지 결정한다.

문지기는 명단을 꼼꼼히 확인하고 알맞은 손님에게 금빛 손목띠를 채워 줬다. 옆의 공동 보관함이 그 손목띠를 복사해 명단 밖 손님에게도 내민다면, 출입 판단은 어디서 잘못됐을까. IETF CDNI 엣지 제어 메타데이터 초안 -13판은 이 비유를 웹 출처 허용 목록, 와일드카드 CORS 헤더, 공유 캐시라는 실제 구성요소로 풀어낸다.

상위 CDN은 RFC 8006의 메타데이터 인터페이스를 통해 하위 CDN에 MI.CrossoriginPolicy를 보낼 수 있다. 하위 CDN은 요청의 Origin을 허용 목록과 대조한다. 일치하고 wildcard-return이 켜져 있으면 Access-Control-Allow-Origin: *를 응답에 넣을 수 있다. 일치하지 않으면 해당 CORS 헤더를 넣지 않는다. 별표 자체에는 누가 목록 검사를 통과했는지 쓰여 있지 않다.

그 빈칸을 캐시가 사고로 채울 수 있다. 첫 출처에 보낸 별표 응답이 공유 캐시에서 Origin에 따라 구별되지 않고 다른 요청에 재사용되면, 제외된 출처의 브라우저도 그 별표를 받는다. -13판에 추가된 운영 설명이 바로 이 경로를 지적한다. 초안은 하위 CDN이 CORS 헤더를 저장된 자원 표현에 박아 두지 말고 응답마다 생성하도록 요구한다. 결과에 영향을 주는 요청 헤더 이름도 Vary에 넣어야 한다.

이전 -12판은 설정 객체를 정의했다. 새 판은 설정이 무엇을 통제하는지도 또렷이 한다. CORS 헤더는 브라우저가 다른 출처의 스크립트에 응답을 공개할지 판단할 때 읽는다. 헤더가 빠져도 하위 CDN은 공개 자원을 제공한다. 브라우저가 인증 정보를 포함하는 include 모드 요청은 여기서 다루는 객체의 범위 밖이다. 인증과 권한 부여까지 엮으려면 설정 외의 동작이 필요하다.

정책이 도착하는 시간도 다르다. 상위 CDN이 자원을 먼저 열고 하위 CDN에는 아직 정책이 적용되지 않았다면, 하위는 CORS 헤더 없이 응답한다. 그동안 브라우저의 교차 출처 검사는 실패한다. 새 운영 절은 RFC 8006의 기존 방법으로 하위 CDN의 현재 설정을 읽고 실제 응답과 비교할 수 있다고 적었다. 별도의 새 감시 장치는 만들지 않는다. 보낸 규칙, 도착한 규칙, 브라우저가 본 결과가 각각 확인돼야 한다.

IETF 문서 기록에 따르면 -13판은 IESG 평가 단계의 CDNI 작업반 초안이다. 운영자가 챙길 질문은 명단이 맞았는지에서 끝나지 않는다. 마지막 손목띠가 누구에게 갔는지까지 봐야 한다.