Встроенный в браузер HTML Sanitizer API: прощай, DOMPurify? 🛡
Нативная санитизация HTML: безопасные и unsafe-методы, сценарии использования, роль бэкенда и поддержка браузерами.
Все мы когда-то рендерили пользовательский контент через innerHTML и боролись с XSS-уязвимостями. Де-факто стандартом для очистки HTML всегда был DOMPurify. Инструмент отличный, но он тащит в бандл ~23 КБ кода и вынужден дублировать работу браузера по парсингу, постоянно догоняя новые фичи веб-платформы.
В блоге Ахмада Алфи вышел отличный разбор нового HTML Sanitizer API, который наконец-то переносит задачу санитизации на уровень самого браузера.
Главное из статьи:
- Два семейства методов: Безопасные (
setHTML,parseHTML) и небезопасные (setHTMLUnsafe,parseHTMLUnsafe).
— Safe by default:setHTML()работает максимально жестко. Он вырежет любые опасные теги иon*атрибуты, даже если вы попытаетесь явно разрешить их через конфиг-объект.
— Unsafe-методы как escape hatch:setHTMLUnsafe()пригодится, если вам нужно прокинуть Declarative Shadow DOM, или вы полностью отдаете себе отчет, зачем осознанно разрешаете инлайн-скрипты.
— Идеальные юзкейсы: Optimistic UI (безопасно рендерим коммент на клиенте сразу, пока ждем ответ сервера), очистка грязного HTML при вставке (например, из Word) и превью Markdown.
— Бэкенд всё еще важен: Клиентский Sanitizer API — это про UX и моментальную защиту в браузере. Базовую очистку данных на бэкенде никто не отменял.
Что по поддержке?
В феврале 2026 года Firefox 148 первым выкатил стабильную реализацию. Chrome пока прячет фичу за флагом, а Safari только высказал позитивное отношение без активной разработки. Пока API не станет Baseline, используем подход с feature detection и оставляем DOMPurify как фоллбэк.
Как думаете, когда сможем полностью выпилить DOMPurify из продакшена? Или хвост старых браузеров не отпустит нас еще лет пять? 👇