Составьте реестр кода и условий загрузки
Начните с аналитики, чатов, виджетов, рекламных тегов и менеджеров тегов. Укажите, кто добавляет код, кто может публиковать изменения и для какой задачи он нужен. Один контейнер может загружать несколько компонентов и менять их без редактирования исходной страницы.
Для каждого компонента отметьте страницы, действия пользователя и другие условия появления. Набор до взаимодействия с виджетом может отличаться от набора после. Отсутствие запроса в одном открытии страницы не доказывает, что компонент никогда не передает информацию.
Разделяйте адрес загрузки кода и адрес назначения данных. Файл с одного домена может обращаться к другим разрешенным назначениям. Для каждого наблюдения сохраняйте дату и условия, а неизвестные ветки передавайте владельцу на проверку.
Понимайте контекст исполнения и пределы доступа
OWASP обращает внимание на доверие к стороннему JavaScript и менеджерам тегов. Скрипт, выполняющийся в контексте страницы, может работать с доступным ей содержимым. Размещение файла на внешнем сервере само по себе не изолирует его от страницы.
Это не означает доступ ко всем данным браузера или любых сайтов. Реальная область зависит от контекста исполнения, политик браузера и конструкции компонента. Изолированная рамка и код в основной странице требуют разного разбора.
MDN указывает, что HttpOnly запрещает JavaScript доступ к значению соответствующего cookie. Но такие cookie могут отправляться с запросами, инициированными скриптом, в применимых условиях. Наличие HttpOnly не превращает весь код страницы в изолированный или безопасный.
Слой данных помогает договориться, какие значения предназначены для аналитики, но не является песочницей для кода. Аналогично серверный сборщик не изолирует скрипты, которые по-прежнему работают в браузере. Проверяйте фактическую архитектуру, а не только название подхода.
Реестр маршрута, контекста и решения
Форма CyberFixCrew связывает деловую задачу с техническим наблюдением. Владелец должен понимать, какие значения доступны компоненту, какие реально передаются и кто может изменить это поведение. Доступность информации и наблюдаемая передача - разные факты.
Для неизвестного назначения запишите вопрос и ответственного, не делая вывода об отсутствии риска. Приоритет получают страницы и процессы с чувствительным вводом. В реестр достаточно описаний и безопасных подтверждений; реальные сообщения посетителей собирать ради таблицы не нужно.
| Область | Что выяснить | Решение владельца |
|---|---|---|
| Назначение | Какой функции нужен код | Нужность подтверждена |
| Загрузка | Когда и откуда появляется | Условия известны |
| Контекст | Где выполняется компонент | Граница доступа описана |
| Данные | Что доступно и что отправляется | Состав согласован |
| Изменения | Кто публикует новую версию | Права и обзор определены |
| Приемка | Какие маршруты проверяются | Функция и ограничения записаны |
Не смешивайте CSP, SRI и решения о приватности
CSP может ограничивать определенные источники и действия в браузере согласно выбранной политике. Режим report-only формирует отчеты, но не применяет объявленное ограничение. Нужен разбор фактического режима и области, а не только присутствия заголовка.
Subresource Integrity позволяет сверить загружаемый ресурс с ожидаемым криптографическим хешем. Для межсайтовой загрузки с SRI учитываются условия CORS. Это проверка соответствия ожидаемому содержимому, а не доказательство безвредности самого разрешенного кода.
Если компонент меняется динамически, применимость фиксированного хеша требует отдельного решения. Обновление политики или целостности должно сохранять нужную функцию и иметь приемку. Не вставляйте универсальный набор правил без учета реальных зависимостей сайта.
Ни CSP, ни SRI не определяют автоматически правомерность сбора и согласия пользователя. Допустимость обработки, состав данных и выбранный пользовательский сценарий согласуются отдельно с учетом применимых требований. Техническое разрешение запроса и деловое решение о передаче дополняют друг друга.
Планируйте проверку полного сценария
Используйте вымышленные значения и разрешенную тестовую область. Сравните загрузку страницы, взаимодействие с виджетом, отправку формы и ветку ошибки. При необходимости рассматривайте разные состояния согласованного механизма выбора пользователя.
Проверяйте отсутствие лишнего назначения и сохранность нужной функции: обращения, аналитического события или интерфейса. Сбой одного компонента не должен незаметно создавать новый маршрут или повторную передачу. Наблюдение относится к проверенным условиям.
Сетевой журнал может содержать параметры и сведения о сеансе. Ограничьте сбор, хранение и передачу подтверждений. Для обсуждения обычно достаточно перечня назначений, типов значений и безопасных фрагментов, а не полного архива пользовательской активности.
Поддерживайте минимальный нужный набор компонентов
Для каждого скрипта назначьте владельца, цель и повод для пересмотра. Новый тег, смена поставщика, изменение контейнера или полей формы могут менять маршрут данных. Права публикации в менеджере тегов рассматривайте как доступ к изменению поведения сайта.
Удаление неиспользуемого компонента согласуют с владельцем процесса и проверяют по нужным функциям. В итоговом реестре остаются известные маршруты, исключения и открытые вопросы. Отсутствие видимого баннера или ошибки не доказывает правильность обработки информации.
CyberFixCrew - израильская компания для русскоязычных бизнесов по всему миру. Практические знания израильской команды в защите сайтов и цифровой инфраструктуры помогают разбирать сторонний код, браузерные политики и интеграции вместе. Состав наблюдений, допустимые изменения и приемка определяются для вашего сайта.
