CRM-аналитика
Как проверить, что динамический текст не раскроет чужие данные
Время чтения: 4 мин
Уровень материала: Для экспертов
Содержание
Персональное письмо показывает имя, заказ и доступные бонусы. При проверке на одном тестовом профиле всё выглядит правильно. Но массовая отправка использует другой контекст, общий кеш или ошибочно связанное событие — и покупатель получает сведения другого человека.
Динамический контент — часть сообщения, которая формируется из данных получателя и события. Его безопасность зависит не только от синтаксиса переменной. Нужно доказать, что выбранные данные принадлежат нужному адресату и доступны ему в конкретной ситуации.
Определите контекст каждой переменной
Для каждого поля запишите источник, владельца данных и условие использования. Имя может приходить из профиля, номер заказа — из события покупки, баланс — из бонусной системы. Сочетание этих источников требует надёжной связи идентификаторов.
Проверьте, кто является получателем: владелец аккаунта, плательщик, получатель подарка или представитель компании. Один email в заказе не всегда означает право показывать всю историю профиля.
OWASP рекомендует проверять разрешение на доступ к конкретному объекту; сложный или непредсказуемый идентификатор сам по себе такую проверку не заменяет. Это особенно важно для ссылок из письма на заказ, обращение или личный документ. [1]
Почему пустое поле — не главная опасность
Отсутствие имени обычно приводит к неудачному приветствию. Гораздо опаснее существующее, но чужое значение. Поэтому запасной текст должен включаться не только при пустом поле, но и при неподтверждённом соответствии данных адресату.
Не подставляйте «последний заказ» без указания, чей и в каком контексте. Не берите тестовый профиль как запасной источник. Для критичного блока лучше убрать персональные сведения и дать нейтральный переход в защищённый кабинет.
Кеш — временное хранение уже подготовленного результата — тоже требует проверки. Общий информационный блок можно переиспользовать, а персональный результат нельзя случайно отдать другому получателю из-за слишком общего ключа хранения.
Матрица проверки перед отправкой
| Сценарий | Что должно произойти |
|---|---|
| Профиль А и его заказ | Отображаются только разрешённые данные А |
| Профиль А и ошибочно переданный заказ Б | Отправка блока отклонена или выбран нейтральный вариант |
| Данные отсутствуют | Осмысленный запасной текст без чужих значений |
| Последовательная обработка А и Б | Значения А не сохраняются в сообщении Б |
| Повтор после обновления профиля | Используется согласованная версия данных |
| Ссылка открыта другим тестовым пользователем | Чужие данные недоступны |
OWASP описывает проверку прав с несколькими тестовыми аккаунтами и разными объектами. Используйте этот подход в своей разрешённой тестовой среде, с синтетическими данными и заранее ожидаемыми результатами. [2]
Условный пример
В письмо о доставке вставляют список товаров из события заказа. Получателя определяют по профилю, найденному по телефону. В базе есть ошибочно объединённые записи двух людей. Шаблон сам по себе исправен, но письмо уходит не тому человеку.
Одного теста в редакторе недостаточно: нужно проверить всю цепочку — событие, разрешение идентификатора, адрес назначения и готовый результат. Для тестовых клиентов полезны хорошо различимые имена и товары, чтобы перепутывание было заметным.
Другой сценарий: ссылка на заказ содержит длинный случайный идентификатор и открывает сведения без дополнительного ограничения. Длина адреса не доказывает безопасность. Для чувствительных сведений нужно проверить предусмотренную модель доступа, срок и область действия ссылки; пересылка письма не должна непреднамеренно раскрывать лишнее.
Что сохранять для расследования
Фиксируйте идентификатор отправки, версию шаблона, идентификаторы профиля и события, результат проверки соответствия и применённый запасной вариант. Не копируйте в журнал все персональные поля без необходимости: сам журнал тоже требует защиты.
Предпросмотр и тестовую отправку проверяйте отдельно от массового процесса. У них могут различаться момент получения данных, способ подстановки и доступные права.
Если обнаружено смешение данных, остановите затронутый сценарий и сохраните необходимые сведения для расследования с ограниченным доступом. Уже доставленное письмо обычно нельзя отозвать изменением шаблона. Нужно определить затронутые сообщения, закрыть доступ к ошибочным веб-страницам и передать инцидент ответственным за безопасность и работу с клиентами.
Критерий готовности — не просто красивый персональный текст. Команда должна показать, что при ошибке данных система не превращает неопределённость в чужую персонализацию.
Источники
1. OWASP Foundation. Authorization Cheat Sheet. OWASP Cheat Sheet Series. Проверено 22.09.2026.
2. OWASP Foundation. Insecure Direct Object Reference Prevention Cheat Sheet. OWASP Cheat Sheet Series. Проверено 22.09.2026.