Ограничить перезапись содержимого прокси с помощью no-transform и HTTPS

Прокси, преобразующий содержимое, может изменить ответ на пути к браузеру: пересжать изображение, переписать разметку или вставить вспомогательный JavaScript. Страница, которая работает в одной сети и получает незнакомую разметку в другой, может сталкиваться именно с таким поведением посредника.

Для сайта, которым вы управляете, HTTP предоставляет явную директиву ответа:

Cache-Control: no-transform

RFC 9111 требует, чтобы посредник, получивший эту директиву ответа, оставил содержимое непреобразованным, независимо от того, реализует ли он кеш. Это касается пересжатия изображений и внедрения разметки, а не только того, будет ли объект сохранён.

Сохраняйте её вместе с существующей политикой кеша

Если у ответа уже есть директивы кеша, добавьте требование осознанно, а не отбрасывайте остальную политику. Например, публично кешируемый ресурс может иметь:

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

Этот пример сохраняет политику свежести в один час и при этом запрещает преобразование содержимого. no-transform не подразумевает no-store и не отключает обычную обработку передачи. Устанавливайте её в ответах, исходное содержимое которых важно, включая отдельные ответы с изображениями, где это уместно.

Директива работает благодаря соблюдению со стороны посредника. Она криптографически не мешает сетевому устройству проигнорировать инструкцию.

Защитите и транспорт

HTTPS даёт браузеру соединение с аутентификацией и защитой целостности до его узла TLS. Обычный прокси оператора, пропускающий зашифрованный трафик, не может незаметно вставить скрипт в это защищённое соединение. Оставляйте проверку сертификатов включённой; локально доверенный инспекционный прокси, завершающий TLS, — это другая схема.

Отдавайте страницу и зависимые от неё ресурсы по HTTPS. Перенаправляйте посетителей HTTP на HTTPS и рассмотрите HSTS для развёртывания, которое может последовательно его поддерживать. Одно лишь перенаправление начинается с незащищённого обмена HTTP для посетителя, использовавшего HTTP-адрес; ранее изученная или предварительно загруженная политика HSTS меняет этот первоначальный выбор.

Блокировка внедрённого скрипта может уменьшить его видимые эффекты, но ответ может уже содержать изменённый HTML или перезаписанные URL изображений. Замена одного старого имени функции, добавление необычного комментария или сопоставление исторического адреса внедрения не устанавливает целостность содержимого для следующего посредника.

При разборе сообщения сравните полученный ответ с предполагаемым содержимым источника и определите, где завершается TLS. Это свидетельство полезнее, чем считать каждый незнакомый скрипт ошибкой в собственном коде приложения сайта.