Сообщение из iframe: как проверить отправителя и данные

Получатель postMessage должен проверить ожидаемый origin, конкретное окно-отправитель там, где это предусмотрено обменом, и структуру данных до выполнения действия. Сообщение от разрешённого виджета не даёт ему любых полномочий в приложении. Для отправки укажите точный targetOrigin, если происхождение получателя известно.

Одна задача виджета — один понятный договор

Рассмотрим учебный интерфейс: на странице находится встроенный виджет, который сообщает свою высоту. Родительская страница должна изменить размер его области. Из этого требования не следуют права менять заказ, отмечать оплату или запускать произвольную команду.

Перед программированием запишите участников, направление сообщения, допустимый тип и единственное разрешённое действие. Если поставщик приносит «универсальный обработчик всех сообщений», попросите объяснить каждую поддерживаемую операцию. Неизвестный тип не должен становиться новой функцией только потому, что сообщение удалось прочитать.

Сам механизм Window.postMessage на MDN предназначен для контролируемого обмена между окнами, включая страницу и iframe. Наличие такого канала не отменяет проверок со стороны приложения.

Какой origin ожидали и какое окно встроили

Origin описывает происхождение отправителя в момент вызова postMessage: схему, имя узла и порт. Это не полный адрес страницы с путём. MDN также уточняет, что такое значение не гарантирует текущее или будущее происхождение окна после навигации.

Проверяйте точное ожидаемое значение. Поиск знакомого фрагмента в строке не задаёт надёжную границу доверия. Если разрешены разные среды поставщика, перечислите их явно и объясните назначение каждой, не смешивая тестовый и рабочий обмен.

Свойство source ссылается на окно, отправившее сообщение. Для нашего примера получатель сопоставляет его с окном конкретного встроенного виджета. Это помогает не перепутать сообщения разных экземпляров, даже когда они загружаются с одного разрешённого происхождения.

Карточка приёмки сообщения изменения высоты

Следующая таблица — предлагаемая спецификация условного resize-обмена. Ограничения значений согласовываются с дизайном страницы. Это не результат испытания реального виджета и не универсальная схема для любого интеграционного сообщения.

Разрешённый отправитель тоже может прислать ошибку

В рекомендациях OWASP по Web Messaging проверки происхождения и содержимого рассматриваются отдельно. Обмен следует трактовать как передачу данных. Не нужно исполнять полученное содержание как программу или без проверки вставлять его в разметку страницы.

Для учебной высоты определите числовой тип, единицы измерения и конечный диапазон. Что делать с отсутствующим полем, неподдерживаемой версией или лишним типом операции, решите до запуска. Успешное чтение JSON подтверждает только возможность разобрать этот формат.

Оставьте проверку рядом с границей получения. Иначе один разработчик может проверить событие, а другой — позже передать необработанные данные в общий обработчик. В описании интерфейса должно быть видно, какие сведения уже проверены и какое действие после этого допустимо.

Ответное сообщение: адрес назначения тоже проверяется

При отправке MDN рекомендует задавать точный targetOrigin вместо звёздочки, когда получатель известен. Он должен совпадать с происхождением получателя, включая схему, узел и порт. Проверка входящего origin не подменяет эту настройку исходящего обмена.

Не пересылайте обратно всё полученное событие «для подтверждения». Состав ответа определите в том же договоре: достаточно ли сообщить принятие размера или требуется код отказа. Так в обмен не попадут случайные данные страницы, которые виджет не запрашивал.

Два виджета, повторная загрузка и устаревшее событие

Полезная проверка интерфейса — представить два одинаковых виджета рядом. Сообщение первого должно менять только его область. Общий разрешённый origin не отвечает на вопрос, к какому экземпляру относятся данные. Здесь нужен учёт конкретного окна и состояния компонента.

Затем представьте, что пользователь сменил раздел, а приложение заменило встроенный элемент. Укажите, когда прекращается действие старого договора. При повторной инициализации не стоит применять старые сообщения к новому состоянию только из-за совпадения названия операции.

Это проектные сценарии для собственной среды. Их можно проверить на небольших безобидных данных, без доступа к чужим страницам и без передачи реальных учётных сведений. Задача приёмки — подтвердить границы обновления интерфейса.

Где заканчиваются полномочия браузерного события

Если позже виджет должен инициировать изменение заказа, одной поддержки нового типа сообщения недостаточно. Нужен отдельный серверный контракт: кто действует, над какой записью и с какими правами. Для получателя сообщение может быть запросом к действию, но не доказательством разрешения.

Мы советуем не расширять обработчик высоты до универсальной шины команд без отдельного разбора. Полезно держать таблицу операций: какая меняет только представление, а какая требует подтверждения сервером. Для каждой предусмотрите отказ, не оставляющий пользователя в неопределённом состоянии.

Чек-лист перед подключением виджета

1. Опишите ожидаемые окна, происхождения и направления передачи.
2. Зафиксируйте типы сообщений, версии и разрешённые действия.
3. Проверьте точное сравнение origin и соответствие source нужному экземпляру.
4. Проверьте формат и границы каждого используемого значения.
5. Укажите точный targetOrigin в предусмотренном исходящем обмене.
6. В своей тестовой среде проверьте два экземпляра, замену виджета и неподдерживаемый формат.
7. Отделите обновление интерфейса от операций, которым нужна серверная авторизация.

При аудите SaaS пригодятся карточки сообщений и список их действий. В разработке веб-приложения согласуйте контракт с поставщиком до подключения. Для доработки виджета передайте ожидаемое поведение при отказе вместе с успешным сценарием.