Интернационализация в JavaScript-приложениях часто становится скрытой зоной риска: данные, полученные из внешних источников (CMS, пользовательский ввод, API переводов), проходят через слой форматирования и попадают в UI. Библиотека Globalize, опирающаяся на CLDR-данные, предоставляет инструменты форматирования чисел, дат, сообщений и склонений, но не выполняет автоматическую санитарную обработку вывода. Это создаёт условия, при которых неправильная композиция форматтеров может привести к инъекциям на уровне отображения.
Ключевой принцип: Globalize безопасен только в пределах корректного использования форматирования; безопасность итогового вывода определяется контекстом рендеринга.
Наиболее распространённый риск возникает при использовании результата форматирования как HTML без экранирования.
Globalize возвращает строки, не содержащие HTML-санитизации. При
последующей вставке в innerHTML возможно выполнение
внедрённой разметки:
messageFormatterДаже если CLDR-шаблоны корректны, источник опасности находится в данных, а не в библиотеке.
Критический сценарий возникает при смешении:
Globalize поддерживает форматирование сообщений на основе ICU-подобных шаблонов. При динамическом формировании шаблонов без контроля возможно подмешивание управляющих конструкций.
Опасные паттерны возникают при:
Проблема заключается не в синтаксисе CLDR, а в том, что шаблон сообщения становится интерпретируемым кодом форматирования.
Даже при статических шаблонах инъекция возможна через параметры:
Особую опасность представляют:
Такие данные способны искажать визуальное представление интерфейса без нарушения синтаксиса HTML.
Globalize часто используется совместно с HTML-шаблонизаторами, React/Vue или серверным рендерингом. Ошибки возникают при переходе между контекстами:
Особенно опасна ситуация, когда форматированная дата или число становится частью HTML-атрибута без кавычек или экранирования.
Globalize выполняет строго определённую функцию:
При этом отсутствуют механизмы:
Это означает, что библиотека находится на уровне логики представления, а не безопасности.
Наиболее частая причина уязвимостей:
+Такой подход разрушает структуру шаблонов и переносит ответственность за экранирование на внешние слои.
Любой результат Globalize может содержать данные, пришедшие из недоверенного источника. При вставке в DOM через HTML-интерпретатор создаётся поверхность для XSS.
Особенно опасно сочетание:
Если локализация загружается динамически (CMS, API, админ-панель), появляется риск внедрения:
Отсутствие валидации на уровне хранилища переводов переносит уязвимость в рантайм.
Форматирование через Globalize должно оставаться изолированным от логики рендеринга HTML. Результат рассматривается как plain text до момента безопасного экранирования.
Шаблоны сообщений должны считаться кодом конфигурации:
Любая динамическая генерация шаблонов увеличивает поверхность атаки.
Безопасность обеспечивается не Globalize, а слоем отображения:
Особое внимание требуется к символам:
LRE, RLE,
PDF)Фильтрация или нормализация данных снижает риск визуальных атак и подмены смысла текста.
ICU-подобные шаблоны в Globalize поддерживают структурную интерполяцию. При неправильной архитектуре сообщения начинают вести себя как мини-язык выражений.
Риски усиливаются при наличии:
Любая интерпретация пользовательских данных внутри шаблона превращает систему в потенциальный вектор инъекций.
Безопасная интеграция Globalize обычно строится вокруг следующих ограничений:
Такая модель снижает вероятность перехода от i18n к XSS и template injection.
Интернационализация увеличивает количество входных точек:
Каждый слой добавляет потенциальный канал внедрения данных. Globalize лишь формализует представление этих данных, но не ограничивает их происхождение, поэтому безопасность определяется архитектурой приложения, а не библиотекой.