РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-21
Как безопасно показывать Markdown из ответа нейросети
Практический разбор рендеринга чата: где заканчивается форматирование и начинается доверие к чужому содержимому.
Текст модели следует считать недоверенным содержимым, даже если запрос отправил авторизованный пользователь. Для Markdown задайте ограниченный набор возможностей, затем очищайте полученный HTML перед вставкой в страницу. Не полагайтесь на то, что форматтер автоматически удалит опасные элементы: например, Marked прямо предупреждает, что не очищает HTML. Отдельно проверьте ссылки, изображения и расширения для диаграмм. Ответ из истории диалога проходит те же правила, что и новый потоковый ответ.
1. Определите разрешённый формат
Начните с абзацев, списков, таблиц и блоков кода. Если встроенные формы, iframe и произвольный HTML не нужны пользователю, не включайте их ради совместимости со всем Markdown. Исходный код из ответа показывайте как текст, а не как выполняемую страницу. Для каждого расширения запишите, какие данные оно принимает и какой DOM создаёт. Обработчик математических формул или диаграмм тоже является частью поверхности проверки, а не доверенным исключением.
2. Соберите последовательный конвейер
Разберите Markdown выбранной библиотекой, очистите итоговую разметку поддерживаемым санитайзером и только затем вставляйте её в документ. Конкретные настройки зависят от библиотеки и разрешённых возможностей. Не добавляйте после очистки произвольные атрибуты и HTML из исходного ответа: так можно снова внести опасное содержимое. Если библиотека обновилась, повторите контрольные случаи. Сохраняйте исходный текст для истории отдельно, но никогда не отображайте его как доверенный HTML при повторном открытии.
3. Проверьте адреса и загрузку ресурсов
Разрешённый тег ссылки ещё не делает безопасным её адрес или подпись. Ограничьте допустимые схемы URL и явно оформляйте переход на внешний сайт. Изображение по внешнему адресу может создавать сетевой запрос уже при показе сообщения, поэтому выберите правила загрузки заранее. Не подставляйте секреты из приложения в адреса, предложенные моделью. Если продукт использует прокси изображений, для самого прокси нужны ограничения адресов и размера загружаемого ресурса.
4. Проверьте поток и сохранённую историю
В контрольный набор включите HTML внутри Markdown, необычные адреса ссылок, вложенные элементы, незавершённый блок кода и ответ, который приходит частями. Проверьте переключение между диалогами и повторное открытие сообщения после перезапуска. Безопасность полного документа не доказывает безопасность промежуточного состояния потокового рендера. Дополнительная политика CSP полезна как слой защиты, но не превращает произвольную вставку HTML в безопасную архитектуру. При непонятной ошибке допустим запасной показ обычного текста.
Частые вопросы
Можно ли доверять разметке хорошей модели?
Нет. Источником ответа могут стать пользовательский ввод и внешние документы. Проверка вывода должна работать независимо от выбранной модели.
Нужно ли удалять Markdown полностью?
Не обязательно. Разрешите нужный продукту ограниченный формат и проверьте весь конвейер, включая расширения и повторный показ истории.
Достаточно ли экранировать исходный Markdown?
Это зависит от конвейера. Если затем парсер создаёт HTML, проверять нужно и итоговую разметку. Не смешивайте текстовое экранирование с очисткой HTML.
Блокирует ли санитайзер мошеннический текст?
Он контролирует разметку, а не достоверность сообщения. Обманчивая подпись обычной ссылки или просьба раскрыть пароль требуют отдельных продуктовых правил.