Обмежити переписування вмісту проксі за допомогою no-transform і HTTPS
Використовуйте no-transform, щоб оголосити політику вмісту HTTP, і 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. Це свідчення корисніше, ніж вважати кожен незнайомий скрипт помилкою у власному коді застосунку сайту.