Trusted Types: як браузер допомагає зменшити ризик DOM XSS

Trusted Types допомагає захистити вебзастосунок від DOM-based XSS, забороняючи передавати звичайні рядки у небезпечні DOM sinks. Код має створити типізоване значення через схвалену policy, де централізовано виконується санітизація або перевірка походження.

Чому DOM XSS важко знайти

Сторінка може отримати рядок із URL, postMessage або API й передати його в innerHTML, document.write чи інший sink. Сервер не обов’язково бачить небезпечний payload, а звичайне HTML-escaping може застосовуватися не в тому контексті.

Від рядка до TrustedHTML

Після ввімкнення enforcement небезпечний sink приймає не довільний string, а TrustedHTML або інший відповідний тип. Значення створює policy через trustedTypes.createPolicy. Це робить місця формування небезпечного контенту видимими для review.

CSP require-trusted-types-for

Директива Content Security Policy require-trusted-types-for 'script' вмикає enforcement у підтримуваному браузері. Директива trusted-types може обмежити дозволені назви policies. Починати варто з report-only режиму, щоб знайти sinks і бібліотеки, які потребують адаптації.

Default policy — тимчасовий міст

Default policy може перехоплювати старі виклики й повертати sanitized value. Якщо вона просто повертає вхідний рядок, захист стає декоративним. Краще мігрувати код до вузьких іменованих policies, а default використовувати лише з вимірним планом видалення.

Trusted Types працює разом з іншими response controls. Наприклад, Permissions Policy обмежує доступ iframe до можливостей браузера, але не захищає HTML sinks.

Санітизація залежить від контексту

Trusted Types не містить універсального sanitizer. Policy повинна використовувати зрілу бібліотеку й конфігурацію для конкретного контексту. TrustedHTML не можна підставляти як script URL або JavaScript; різні типи існують саме через різні моделі небезпеки.

Third-party та legacy код

Старі UI-бібліотеки можуть широко використовувати innerHTML. Під час міграції збирають звіти, групують порушення за stack trace, оновлюють залежності й створюють мінімальні adapters. Дозвіл policy для всього vendor bundle повертає надмірні повноваження.

Порядок впровадження

• увімкнути CSP Report-Only і зібрати реальні порушення;
• видалити непотрібні sinks та перейти на textContent і DOM API;
• створити вузькі policies з перевіреним sanitizer;
• обмежити назви policies через CSP;
• увімкнути enforcement і додати браузерні regression tests.

Межі захисту

Trusted Types не зупинить логічну помилку, небезпечний backend template або скомпрометований дозволений script, який має доступ до policy. Проте механізм істотно скорочує клас випадкових DOM XSS і концентрує найбільш ризикові перетворення у місцях, які можна аудіювати.

Policy ownership і review

Кожна policy має конкретного власника, коротку мету та тестові приклади небезпечного input. Створення нової policy проходить security review, бо це новий канал до sink. Центральний registry назв допомагає уникнути випадкових дублів і надто загальних функцій на кшталт createAnything.

Метрики міграції

Команда відстежує кількість порушень за route, bundle і sink, частку коду без default policy та браузерну підтримку. Мета — не просто зменшити число звітів, а видалити небезпечні потоки. Фільтрування однакового stack trace корисне, але не повинно приховувати новий attacker-controlled input.

Першоджерело: W3C Trusted Types.