no-transform과 HTTPS로 프록시 콘텐츠 재작성 제한하기

콘텐츠를 변환하는 프록시는 브라우저로 가는 도중 응답을 바꿀 수 있습니다. 이미지를 다시 압축하거나, 마크업을 다시 쓰거나, 보조 JavaScript를 삽입합니다. 한 네트워크에서는 작동하던 페이지가 다른 네트워크에서 낯선 마크업을 받는다면 바로 그 중간자의 동작을 겪고 있을 수 있습니다.

운영하는 사이트의 경우 HTTP는 명시적인 응답 지시자를 제공합니다.

Cache-Control: no-transform

RFC 9111은 이 응답 지시자를 받은 중간자가 캐시를 구현하든 하지 않든 콘텐츠를 변환하지 않고 그대로 두도록 요구합니다. 이는 객체가 저장되는지 여부만이 아니라 이미지 재압축과 마크업 삽입에도 관련됩니다.

기존 캐시 정책과 함께 유지하기

응답에 이미 캐시 지시자가 있다면 정책의 나머지를 버리는 대신 요구 사항을 의도적으로 추가하세요. 예를 들어 공개적으로 캐시 가능한 자산은 다음과 같을 수 있습니다.

Cache-Control: public, max-age=3600, no-transform

이 예시는 1시간의 신선도 정책을 유지하면서 콘텐츠 변환을 금지합니다. no-transform 은 no-store 을 의미하지 않으며 일반적인 전송 처리를 비활성화하지도 않습니다. 원본 콘텐츠가 중요한 응답에 설정하고, 필요하다면 별도의 이미지 응답에도 설정하세요.

이 지시자는 중간자의 준수를 통해 작동합니다. 네트워크 장비가 지시를 무시하는 것을 암호학적으로 막지는 못합니다.

전송도 보호하기

HTTPS는 브라우저에 TLS 피어에 대한 인증과 무결성 보호를 갖춘 연결을 제공합니다. 암호화된 트래픽을 통과시키는 일반 통신사 프록시는 그 보호된 연결에 몰래 스크립트를 삽입할 수 없습니다. 인증서 검증은 그대로 유지하세요. TLS를 종료하는 로컬에서 신뢰하는 검사 프록시는 다른 구성입니다.

페이지와 그 종속 리소스를 HTTPS로 제공하세요. HTTP 방문자를 HTTPS로 리디렉션하고, 일관되게 지원할 수 있는 배포라면 HSTS를 고려하세요. 리디렉션만으로는 HTTP URL을 사용한 방문자에게 보호되지 않은 HTTP 교환으로 시작됩니다. 이전에 학습했거나 미리 로드된 HSTS 정책은 그 최초 선택을 바꿉니다.

삽입된 스크립트를 차단하면 눈에 보이는 효과를 줄일 수 있지만, 응답에는 이미 변경된 HTML이나 다시 쓰인 이미지 URL이 포함되어 있을 수 있습니다. 오래된 함수 이름 하나를 바꾸거나, 이상한 주석을 추가하거나, 과거의 삽입 주소를 매핑하는 것으로는 다음 중간자에 대한 콘텐츠 무결성이 확립되지 않습니다.

보고서를 조사할 때는 수신한 응답을 원본의 의도된 콘텐츠와 비교하고 TLS가 어디서 종료되는지 확인하세요. 그 증거가 낯선 스크립트를 모두 사이트 자체 애플리케이션 코드의 버그로 취급하는 것보다 유용합니다.