Рендеринг Html-строк в react через dangerouslysetinnerhtml: как использовать безопасно

Безопасный рендеринг HTML-строк в React строится вокруг трёх правил: по максимуму избегать dangerouslySetInnerHTML, всегда очищать HTML от потенциального XSS и изолировать места вставки в отдельные компоненты. Ниже - пошаговая инструкция, практичные паттерны, анти-паттерны и "быстрый режим" для продакшн‑использования.

Короткие практические выводы по рендерингу HTML-строк

  • Используйте dangerouslySetInnerHTML только там, где без строкового HTML нельзя (контент из CMS, markdown, почтовые шаблоны).
  • Всегда пропускайте HTML через проверенный sanitizer до попадания в React‑компонент.
  • Никогда не передавайте в dangerouslySetInnerHTML данные напрямую от пользователя или из непроверенного API.
  • Выносите рендеринг HTML‑строк в отдельный "html-viewer" компонент с чётким интерфейсом.
  • Регулярно тестируйте рендеринг HTML строк в React (примеры кода ниже) на XSS и визуальные артефакты.
  • Предпочитайте альтернативы: парсинг в JSX и библиотеки для безопасного рендеринга HTML в React вместо "сырого" dangerouslySetInnerHTML.

Назначение dangerouslySetInnerHTML и случаи применения

dangerouslySetInnerHTML - это прямой аналог innerHTML из DOM, встроенный в React. Он нужен, когда у вас уже есть готовый HTML (обычно из CMS, markdown‑рендера, старого бэкенда) и переписывать его в JSX дорого или невозможно.

Типичные сценарии использования:

  • Контентные страницы из CMS (статьи, лендинги, FAQ, email‑шаблоны).
  • Рендер markdown через внешнюю библиотеку, выдающую HTML.
  • Интеграция со старым сервером, который возвращает уже сформированный HTML‑фрагмент.
  • Встраивание виджетов/скриптов сторонних сервисов (только через строгую изоляцию и политики безопасности).

Кому подходит:

  • Проектам, где часть интерфейса полностью управляется редакторами в CMS.
  • Командам, которым нужен быстрый мост между существующим HTML и новым React‑фронтендом.

Когда не стоит использовать dangerouslySetInnerHTML:

  • Для обычных React‑компонентов, которые вы контролируете - проще и безопаснее описать разметку в JSX.
  • Для динамических списков, карточек, форм - рендер через JSX даст лучшее управление и типизацию.
  • Для контента, в который вмешиваются пользователи, без жёсткой очистки и валидации.

Если вы только начинаете разбираться и ищете "react dangerouslysetinnerhtml обучение", начинайте с минимального количества мест, где вообще разрешён этот механизм, и сразу завязывайте его на слой предобработки HTML.

Безопасность: XSS-риски и принципы защиты

Главный риск dangerouslySetInnerHTML - XSS: выполнение произвольного JavaScript‑кода в браузере пользователя. React защита от XSS при использовании dangerouslysetinnerhtml по умолчанию отсутствует: вы сами отвечаете за чистоту HTML‑строки.

Базовые принципы защиты:

  1. Разделяйте доверенные и недоверенные источники контента. Любой пользовательский ввод и ответы внешних API по умолчанию считаются недоверенными.
  2. Вводите "белый список" HTML‑тегов и атрибутов. Всё, что не входит в список, удаляйте или экранируйте.
  3. Фильтруйте потенциально опасные конструкции. Сюда относятся:
    • <script>, <style>, <iframe>, <object>, <embed>.
    • Инлайн‑обработчики событий: onclick, onmouseover и т.п.
    • URL с протоколами javascript:, data:, vbscript:.
  4. Используйте Content Security Policy (CSP). CSP режет большую часть XSS, даже если опасный HTML прорвался:
    • Запретите inline‑скрипты и eval.
    • Разрешите скрипты только с доверенных доменов.
  5. Логируйте и мониторьте ошибки рендеринга HTML. Любые неожиданные "missing closing tag" или странные артефакты могут означать некорректный (или злонамеренный) HTML.

Перед тем как искать, как безопасно использовать dangerouslysetinnerhtml в react, настройте в проекте минимум: библиотеку для очистки HTML, CSP и линтер/ревью‑правило, запрещающее "сырой" dangerouslySetInnerHTML вне специальных компонентов.

Очистка и подготовка HTML перед вставкой

Надёжная очистка HTML - обязательный шаг. Ниже - практический алгоритм, который легко оформить в отдельный модуль и переиспользовать во всём приложении.

  1. Определите источники HTML и уровень доверия.

    Составьте список: CMS, markdown‑сервис, внешние API, пользовательские поля. Для каждого определите, можно ли ему доверять и есть ли промежуточная валидация на бэкенде.

    • Доверенный HTML (ваши шаблоны, ваши бэкенды с валидацией) - всё равно пропускайте через sanitizer.
    • Недоверенный HTML (пользовательский ввод, внешние сервисы) - подвергайте усиленной фильтрации.
  2. Выберите и установите библиотеку‑sanitizer.

    В экосистеме есть проверенные библиотеки для безопасного рендеринга HTML в React, например DOMPurify или sanitize-html. Выберите одну и вынесите её в отдельный модуль.

    npm install dompurify
    // htmlSanitizer.ts
import DOMPurify from 'dompurify';

export function sanitizeHtml(html: string): string {
  return DOMPurify.sanitize(html, {
    USE_PROFILES: { html: true },
  });
}
  3. Настройте "белый список" тегов и атрибутов.

    Под конкретный проект задайте, какие теги допустимы: заголовки, абзацы, списки, ссылки, изображения и т.п. Остальное - убирайте.

    // пример конфигурации DOMPurify
const ALLOWED_TAGS = ['a', 'p', 'strong', 'em', 'ul', 'ol', 'li', 'h2', 'h3', 'img'];

DOMPurify.setConfig({
  ALLOWED_TAGS,
  ALLOWED_ATTR: ['href', 'src', 'alt', 'title', 'target', 'rel'],
});

    Храните конфигурацию в одном месте, чтобы при изменениях не править десятки компонентов.

  4. Реализуйте обёртку‑компонент для рендеринга HTML.

    Создайте компонент, который внутри использует dangerouslySetInnerHTML, но снаружи принимает только строку HTML и сам её очищает.

    // SafeHtml.tsx
import React from 'react';
import { sanitizeHtml } from './htmlSanitizer';

type SafeHtmlProps = {
  html: string;
  className?: string;
};

export const SafeHtml: React.FC<SafeHtmlProps> = ({ html, className }) => {
  const clean = sanitizeHtml(html);

  return <div className={className} dangerouslySetInnerHTML={{ __html: clean }} />;
};

    После этого запретите прямой вызов dangerouslySetInnerHTML вне SafeHtml через ревью или линтер.

  5. Интегрируйте компонент и добавьте тесты.

    Замените все места с рендерингом HTML строк в React (примеры кода выше) на <SafeHtml />. Добавьте тесты, гарантирующие, что опасные теги/атрибуты удаляются.

    // пример использования
<SafeHtml html={article.bodyHtml} className="article-body" />
    // пример теста
it('removes script tags', () => {
  const dirty = '<p>Hi</p><script>alert(1)</script>';
  const clean = sanitizeHtml(dirty);
  expect(clean).toBe('<p>Hi</p>');
});
  6. Добавьте защитные заголовки и мониторинг.

    Настройте на бэкенде CSP и другие заголовки безопасности. Подключите фронтенд‑логирование, чтобы отслеживать падения рендеринга, связанные с HTML.

    • Логируйте HTML‑фрагменты, которые вызвали ошибки (с обрезкой по длине).
    • Настройте алерты на всплеск ошибок рендера внутри компонента SafeHtml.

Быстрый режим: минимальный безопасный пайплайн

  • Установите DOMPurify (или аналог) и вынесите sanitizeHtml в отдельный модуль.
  • Создайте компонент SafeHtml, который внутри использует dangerouslySetInnerHTML только с очищенной строкой.
  • Запретите прямой dangerouslySetInnerHTML (правила ревью/линтера).
  • Добавьте хотя бы один тест на вырезание <script> и inline‑обработчиков событий.

Альтернативы рендерингу строк: парсинг в JSX и сторонние библиотеки

Во многих случаях можно вообще обойтись без dangerouslySetInnerHTML, используя парсинг HTML в JSX или специализированные библиотеки.

Чек‑лист для выбора подхода:

  • Нужно ли вам управлять отдельными элементами внутри HTML (вешать React‑обработчики, менять пропсы, подмешивать состояние)? Если да - используйте парсинг в JSX.
  • HTML предсказуемый и структурированный (заголовки, абзацы, списки) - рассмотрите библиотеки, превращающие HTML в React‑элементы, например html-react-parser.
  • Исходный формат - markdown - лучше использовать markdown‑рендерер вроде react-markdown вместо прямого HTML.
  • Нужно тонко управлять безопасностью - комбинируйте парсер с sanitizer: сначала чистка, потом парсинг в JSX.
  • Хотите типобезопасность и автокомплит - спроектируйте собственную модель контента (JSON) и рендерите его через JSX, не через строки HTML.
  • Нужно быстро встроить доверенный HTML‑фрагмент (например, заранее проверенный email‑шаблон) - допустим SafeHtml с очищенной строкой.
  • Есть готовый компонент‑обёртка от сторонней библиотеки для безопасного рендеринга HTML в React - используйте его, но всё равно понимайте, как он очищает данные.

Пример простого парсинга HTML в JSX без прямого dangerouslySetInnerHTML:

import parse from 'html-react-parser';
import { sanitizeHtml } from './htmlSanitizer';

export const ParsedHtml: React.FC<{ html: string }> = ({ html }) => {
  const clean = sanitizeHtml(html);
  return <>{parse(clean)}</>;
};

Реализация в компонентах: паттерны и антипаттерны

Сводка типичных ошибок и удачных практик при внедрении dangerouslySetInnerHTML.

  • Антипаттерн: прямой dangerouslySetInnerHTML в произвольных компонентах. Порождает хаос и дыры в безопасности. Паттерн: один‑два специализированных компонента (SafeHtml, ParsedHtml), всё остальное - через них.
  • Антипаттерн: отсутствие явного контракта по источнику HTML. Когда компонент принимает просто html: string без оговорки "очищено или нет". Паттерн: либо принимаете только "сырой" HTML и внутри всегда чистите, либо явно называете проп unsafeHtml и документируете ответственность.
  • Антипаттерн: повторяющаяся настройка sanitizer по всему коду. Любые расхождения в конфигурации создают непредсказуемость. Паттерн: единый модуль/сервис очистки.
  • Антипаттерн: привязка логики к HTML‑структуре. Например, поиск по document.querySelector после рендера. Паттерн: логика и состояние хранятся в React, HTML‑фрагмент только отображается.
  • Антипаттерн: смешивание CSS и динамического HTML без scope. Глобальные стили могут ломать вёрстку из CMS. Паттерн: оборачивайте HTML‑контент в контейнер с неймспейс‑классом и стилизуйте только внутри него.
  • Антипаттерн: отсутствие SSR‑совместимости. Не учитывается, что HTML будет рендериться на сервере. Паттерн: следите, чтобы очистка HTML была изоморфной (работала и на сервере), либо делайте её на бэкенде.
  • Антипаттерн: динамическая вставка скриптов/виджетов через dangerouslySetInnerHTML. Это почти всегда XSS‑долг. Паттерн: используйте специальные интеграции (SDK, iframe, sandbox‑окна) вместо "сырых" скриптов.

Тестирование, отладка и мониторинг динамического HTML

Надёжная эксплуатация dangerouslySetInnerHTML требует регулярной проверки и наблюдения.

  • Вариант 1: модульные и snapshot‑тесты. Покрывайте sanitizer и компоненты SafeHtml/ParsedHtml тестами: проверяйте вырезание скриптов, inline‑обработчиков, подозрительных протоколов; используйте snapshots для проверки итогового DOM‑дерева.
  • Вариант 2: security‑тесты и fuzzing. Запускайте периодические тесты с XSS‑пейлоадами (готовые списки, генераторы строк), чтобы убедиться, что новые изменения не открыли дыру.
  • Вариант 3: runtime‑мониторинг и логирование. Интегрируйте Sentry/LogRocket/аналог, логируйте ошибки рендеринга HTML, отслеживайте всплески по конкретным страницам и типам контента.
  • Вариант 4: code review‑чек‑лист. Включите отдельный пункт по dangerouslySetInnerHTML в ревью: проверка источника HTML, наличия очистки, использования правильного компонента и соблюдения CSP.

Ответы на типичные сомнения и ограничения

Обязательно ли использовать sanitizer, если HTML приходит из нашей CMS?

Да. Даже если редакторы - только сотрудники компании, ошибки шаблонов или сторонние интеграции внутри CMS могут привести к XSS. Sanitizer - дешёвый слой защиты, который не мешает нормальному контенту.

Можно ли полностью положиться на React для защиты от XSS?

Нет. React экранирует значения, рендеримые через JSX, но при использовании dangerouslySetInnerHTML он доверяет HTML‑строке целиком. Ответственность за безопасность в этом месте полностью на вас.

Когда лучше выбрать парсинг в JSX вместо dangerouslySetInnerHTML?

Когда вам нужно взаимодействие с отдельными узлами HTML: навешивание обработчиков, работа с состоянием, условный рендер подэлементов. Парсинг в JSX даёт больше контроля и лучше интегрируется с остальным React‑кодом.

Нужно ли очищать HTML, если он уже прошёл фильтрацию на бэкенде?

Рекомендуется дублирующая защита. Фильтрация на бэкенде может эволюционировать или содержать баги. Лёгкая очистка на фронтенде снижает риск, даже если бэкенд ошибётся.

Как протестировать, что моя реализация защищена от базовых XSS?

Соберите набор типичных XSS‑пейлоадов (скрипты, javascript:‑ссылки, inline‑обработчики) и прогоняйте их через sanitizer и компонент. Убедитесь, что итоговый HTML не содержит исполняемого кода и не ломает разметку.

Можно ли использовать dangerouslySetInnerHTML в компонентах дизайна‑системы?

Лучше нет. Компоненты дизайна‑системы должны быть максимально предсказуемыми и безопасными. Если очень нужно, выделите отдельный "content"‑компонент с жёсткими правилами использования.

Насколько сложно мигрировать проект, где dangerouslySetInnerHTML используется повсеместно?

Реалистичный план - поэтапная миграция: сначала вводите компонент SafeHtml и оборачиваете все существующие места, затем постепенно заменяете строки HTML на структурированный контент или парсинг в JSX там, где это оправдано.

Post Views: 95

Читайте также

Прокрутить вверх