Svelte 5.52.0 добавляет поддержку TrustedHTML для {@html}, обеспечивая более безопасную интеграцию Trusted Types

Svelte 5.52.0 (опубликовано 18 февраля 2026 года) вводит первоклассную поддержку объектов TrustedHTML в блоках {@html}: Svelte будет принимать и сохранять значения TrustedHTML вместо принудительного приведения их к строкам, что упрощает внедрение API браузерных Trusted Types и снижает риск XSS при рендеринге необработанного HTML. (github.com)

Почему это важно для команд полного стека

• Trusted Types — механизм защиты на уровне браузера, который предотвращает DOM XSS, требуя, чтобы sinks, принимающие HTML (как innerHTML), получали значения, созданные утверждённой политикой. Поддержка на уровне фреймворка означает, что вы можете связать серверную и клиентскую часть Svelte с этой моделью, не давая фреймворку неявно преобразовывать объект TrustedHTML обратно в ненадёжную строку — устраняя целый класс случайных регрессий. (github.com)
• Для приложений с SSR и гидратацией это снижает количество сюрпризов в ситуациях, когда разметка, сгенерированная на сервере, и политики на стороне клиента взаимодействуют. Команды, использующие Content-Security-Policy: require-trusted-types-for 'script' (и связанные политики), смогут внедрять Trusted Types более практически, если Svelte уже на месте. (github.com)

Практичный, высокоэффективный чек-лист обновления

1. Обновитесь до [email protected] (или более поздней версии).
2. Перепроверьте использования {@html}: рассматривайте любые существующие точки входа для неотформатированного HTML как чувствительные к безопасности и по возможности предпочитайте генерировать значения TrustedHTML из известных безопасных источников.
3. Для клиентских Trusted Types:
   • Создавайте HTML через доверенную политику в браузере (policy.createHTML(...)) и передавайте этот TrustedHTML в компоненты, которые рендерят {@html}.
   • Включайте политики CSP Trusted Types на продакшене только после локального тестирования.
4. Для сценариев SSR:
   • Предпочитайте получение очищенных строк на стороне сервера (например, DOMPurify) и на первом включении клиента конвертируйте их в TrustedHTML с помощью политики в браузере перед дальнейшими операциями с DOM — чтобы вывод сервера оставался безопасным и при этом сохранялась совместимость с клиентскими Trusted Types.
   • Либо используйте безопасные схемы сериализации и обеспечьте на клиентской стороне восстановление TrustedHTML через разрешённую политику во время гидрации.
5. Тщательно тестируйте: включите require-trusted-types-for в staging CSP, чтобы выявлять любые места, где всё ещё используются ненадёжные строки.

Подводные камни миграции и рекомендации

• TrustedHTML — это объект времени выполнения браузера; серверы не могут напрямую создавать экземпляр TrustedHTML в браузере. Релиз избегает принудительного преобразования, но это не делает автоматически доверёнными строки, созданные на сервере, на клиенте — ваше приложение должно создавать TrustedHTML на клиентской стороне (или использовать явный, аудируемый поток сериализации → policy.createHTML во время гидрации).
• Не полагайтесь на принудительное преобразование фреймворка для очистки содержимого. Поддержка TrustedHTML снижает трение при внедрении Trusted Types, но вам по-прежнему нужна разумная очистка и явная модель доверия для любого контента от пользователей или третьих лиц. (github.com)

Итог Это выпуск Svelte — прагматическое, прикладное улучшение для команд, которые усиливают защиту веб‑приложений от XSS: он устраняет несоответствие на уровне фреймворка с Trusted Types и делает внедрение защит браузера нативных более прямым — особенно важно для полноценных стэков приложений, которые выполняют SSR и гидрирование сложной разметки. Рассматривайте это как возможность проверить использование {@html}, внедрить или ужесточить политики санитации и спланировать поэтапное развёртывание Trusted Types в staging перед включением строгой CSP в production. (github.com)

Источник:

Источник

• Источник