Коротко
• Iframe меняет поток приёма платежных данных, но не отменяет компрометацию страницы сайта.
• PCI SSC прямо упоминает встроенные формы оплаты в контексте защиты платежных страниц.
• Если страницу сайта можно подменить, атакующий может влиять на поведение процесса оплаты ещё до самой встроенной формы.
Откуда вообще пошла путаница
Исторически PCI SSC различал прямую отправку формы и встроенные формы либо перенаправление. В FAQ по SAQ A и SAQ A-EP совет объяснял: при iframe или перенаправлении платежная страница формируется сторонним процессором, а не сайтом компании. Это важно для охвата и критериев применимости.
Но из этого не следует, что страница сайта больше неважна. PCI SSC отдельно отмечал, что основной вектор атаки против перенаправления и встроенных форм — модификация кода сайта, чтобы направить пользователя не туда или изменить поведение страницы.
Что PCI SSC говорит сейчас
В глоссарии PCI SSC платежная страница может быть не только отдельным документом, но и компонентом внутри встроенного фрейма. А в SAQ A есть прямое примечание: требование 11.6.1 применяется к компаниям, которые размещают на своем сайте встроенную платежную форму стороннего поставщика услуг.
Плюс FAQ 1588 в феврале 2025 года прямо закрепил: критерий SAQ A про скриптовые атаки относится именно к компаниям, у которых есть встроенная платежная страница или форма, например через inline frame.
Где остаётся реальный риск
Даже если данные карты вводятся во встроенную форму провайдера, страница сайта по-прежнему отвечает за DOM, загрузку части скриптов, окружение страницы, HTTP-заголовки, сторонние теги, аналитику, менеджеры согласий и общую границу доверия в браузере клиента.
- можно незаметно внедрить чужой скрипт рядом со встроенной формой оплаты;
- можно подменить логику перенаправления или визуальный слой;
- можно изменить заголовки и поведение страницы во время выполнения;
- можно сломать интеграцию так, что страница перестанет соответствовать инструкциям TPSP.
Практический вывод
Iframe — это не аргумент против защиты на стороне клиента. Это всего лишь другой тип архитектуры, где нужно доказывать, что страница сайта не стала удобной точкой для атаки на процесс оплаты.
Модель угроз для фактической интеграции
Нарисуйте границу iframe и отметьте всё, что остаётся под контролем продавца: контейнер, соседние элементы DOM, менеджер тегов, заголовки, сценарий перенаправления, конфигурацию TPSP и код, способный перекрыть или заменить форму. Для каждого элемента укажите возможное изменение, владельца контроля и доступное доказательство.
Затем проверьте критерии SAQ A и подтверждение поставщика именно для версии интеграции в рабочей среде. Маркетинговое название «hosted checkout» не доказывает, откуда фактически поступают все элементы формы и клиентская логика.
- Подмена назначения перенаправления → контроль конфигурации, релиза и фактического перехода.
- Скрипт рядом с iframe → инвентарь, авторизация, контроль целостности и наблюдение страницы.
- Ослабление заголовка → сравнение значения, которое получил браузер, и маршрут события.
- Изменение интеграции TPSP → проверка инструкции, версии и границ ответственности.
- Руководство по выбору: Защита платёжной страницы после PCI DSS 4.0.1: SAQ A, iframe и доказательства
- HTML-чек-лист: Чек-лист внедрения PCI DSS
Отдельно учтите ASV-сканирование
FAQ 1604 указывает, что требования ASV-сканирования в SAQ A распространяются на страницы продавца как с перенаправлением, так и со встроенным iframe. ASV-сканирование проверяет внешний контур уязвимостей, но не заменяет управление скриптами, наблюдение фактической страницы и процесс обработки изменений.