PCI DSS 4.0: требования 6.4.3 и 11.6.1 к скриптам платёжных страниц

Требования 6.4.3 и 11.6.1 PCI DSS касаются скриптов на платёжных веб-страницах: каждый скрипт должен быть авторизован, проверен на целостность и внесён в перечень с обоснованием, а несанкционированные изменения страницы и HTTP-заголовков должны обнаруживаться. Это «future-dated» требования: они были рекомендациями и стали обязательными с 31 марта 2025 года. Для организаций, принимающих карты онлайн, срок уже наступил.

Зачем появились эти требования

Атаки типа e-skimming (Magecart-подобные) строятся на внедрении вредоносного JavaScript в страницу оплаты: скрипт тихо копирует данные карты прямо в браузере покупателя. Источником может быть как взлом самого сайта, так и скомпрометированная сторонняя библиотека — аналитика, чат-виджет, A/B-тестирование, тег-менеджер. Классические серверные средства защиты такую атаку не видят: вредоносный код исполняется на стороне клиента. Совет PCI SSC описывает цель требований как предотвращение e-skimming за счёт того, что скрипты платёжных страниц одобрены, проверены на целостность и находятся под мониторингом.

Сроки: что значит «future-dated»

При выпуске PCI DSS v4.0 часть новых требований была помечена как лучшие практики до определённой даты. Для требований 6.4.3 и 11.6.1 (а также 12.3.1) такой датой стало 31 марта 2025 года — об этом прямо говорит PCI SSC. Сейчас действует версия v4.0.1, но дата для этих требований не изменилась. Это значит, что при оценке соответствия (QSA-аудит, самооценка) их выполнение проверяется как обязательное.

Требование 6.4.3: управление скриптами

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

• Авторизация. Должен быть метод, подтверждающий, что каждый скрипт разрешён к исполнению.
• Целостность. Должен быть метод, гарантирующий, что содержимое скрипта не изменено.
• Инвентаризация. Ведётся перечень всех скриптов с письменным бизнес- или техническим обоснованием, зачем каждый нужен.

Важно: в перечень входят и скрипты вашего домена, и сторонние, которые подгружаются со внешних серверов, и те, что подтягиваются вторым уровнем (скрипт загружает другой скрипт).

Требование 11.6.1: обнаружение изменений

Пункт требует механизм, который оповещает персонал о несанкционированных изменениях в HTTP-заголовках, влияющих на безопасность, и в содержимом платёжных страниц, как они получаются браузером потребителя. Проверка выполняется периодически; частоту стандарт связывает либо с установленным интервалом, либо с результатами целевого анализа рисков (требование 12.3.1) — точную формулировку и допустимую периодичность проверьте по тексту PCI DSS v4.0.1 на сайте pcisecuritystandards.org. На практике аудиторы ожидают, что вы докажете, что изменение не пройдёт незамеченным.

Кого это касается: полная оценка и SAQ A

Требования применимы к организациям, платёжные страницы которых находятся в области соответствия PCI DSS. Для мерчантов, заполняющих самооценку SAQ A, ситуация особая. Согласно FAQ PCI SSC, пункты 6.4.3 и 11.6.1 были исключены из SAQ A, однако остались в стандарте. Вместо этого появился критерий допустимости: мерчант должен подтвердить, что его сайт не уязвим для атак через скрипты. Это можно сделать двумя способами — применять технические меры, аналогичные 6.4.3 и 11.6.1 (самостоятельно или с помощью третьей стороны), либо получить от PCI-совместимого поставщика платёжных услуг (TPSP) подтверждение, что его решение при правильном внедрении защищает страницу от таких атак. Критерий относится к случаям, когда на странице мерчанта встроена платёжная форма поставщика (например, iframe); при перенаправлении на страницу процессора он не применяется. Какая форма самооценки вам подходит, уточняйте у эквайера и платёжных систем.

Для SAQ A-EP и полной оценки (ROC) пункт 6.4.3 остаётся применимым напрямую.

Как выполнить требования: практический план

1. Определите платёжные страницы. Какие URL принимают и обрабатывают данные карты, включая встроенные формы и редиректы.
2. Составьте перечень скриптов. Автоматически соберите всё, что реально загружается в браузере (не то, что записано в документации): собственные файлы, сторонние домены, цепочки загрузок.
3. Получите обоснование для каждого скрипта. Кто владелец, зачем он нужен на платёжной странице. Всё, что нельзя обосновать, удалите.
4. Обеспечьте авторизацию и целостность. Типовые технические средства: Content Security Policy (CSP) с белым списком источников; Subresource Integrity (SRI) для статичных внешних скриптов; хостинг критичных скриптов у себя. Учтите, что SRI не подходит для скриптов, которые вендор часто и динамически меняет.
5. Настройте мониторинг (11.6.1). Автоматически отслеживайте содержимое страниц и заголовков, как их видит пользователь, и оповещайте при отклонениях от эталона.
6. Встройте процесс. Новый скрипт на платёжной странице проходит согласование, обновляет перечень и эталон мониторинга. Без этого перечень устареет через месяц.
7. Сохраняйте доказательства. Перечень, журналы оповещений, решения по изменениям — аудитору понадобятся артефакты за период.

Типичные трудности

• Невидимые зависимости. Сторонний скрипт подгружает ещё несколько. Статический анализ исходного кода их не покажет — нужен анализ того, что реально исполняется в браузере.
• Динамические изменения вендоров. Сторонние сервисы обновляют код без предупреждения, что ломает SRI и вызывает ложные тревоги.
• CSP ради галочки. Слишком мягкая политика с широкими исключениями формально есть, но защиты не даёт.
• Нет владельцев. Маркетинг добавляет теги, ИБ узнаёт об этом при аудите.

Какие инструменты помогают

Можно закрыть требования комбинацией CSP, SRI и собственных скриптов мониторинга, но поддержка такого решения трудоёмка. Специализированные решения для безопасности клиентской части автоматизируют инвентаризацию, контроль целостности и оповещения. В портфеле AST Cyber Lab для этого есть DPA FAST от DPA Analytics — решение для защиты фронтенда и JavaScript. Подробности возможностей и применимость к вашей схеме оплаты уточняйте на странице продукта или у наших специалистов.

Если вы только строите процесс безопасной разработки, начните с общей картины: DevSecOps: с чего начать и обзор классов инструментов AppSec. Контроль зависимостей фронтенда (npm-пакеты) — задача для SCA, а расширенные требования раздела 6 PCI DSS можно проверять в рамках оценки защищённости приложений.

Статья носит информационный характер и не является юридической консультацией.

Что показать аудитору

Оценщик QSA оценивает не намерения, а артефакты. Для 6.4.3 и 11.6.1 подготовьте заранее:

• актуальный перечень скриптов каждой платёжной страницы с обоснованием и владельцем;
• описание метода авторизации и контроля целостности (политика CSP, список SRI-хэшей, процедура согласования);
• описание механизма обнаружения изменений: что именно отслеживается, как часто, кто получает оповещения;
• журналы срабатываний и разбора инцидентов за период оценки;
• регламент изменений, показывающий, что новый скрипт не попадёт на страницу в обход согласования.

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

С чего начать прямо сейчас

Если срок уже наступил, а процесс не выстроен, действуйте в таком порядке: за неделю-две соберите реальный перечень скриптов платёжных страниц; удалите всё, что нельзя обосновать; включите мониторинг изменений, чтобы начать накапливать доказательства; параллельно ужесточайте CSP и вводите процедуру согласования новых скриптов. Не ждите идеальной архитектуры — частичное выполнение с прозрачным планом лучше, чем отсутствие контролей. Согласуйте график и допустимые компенсирующие меры со своим QSA и эквайером.

Частые вопросы

Источники

• PCI SSC Blog: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025
• PCI SSC FAQ 1588: критерий допустимости SAQ A и скрипты платёжных страниц
• PCI SSC Blog: FAQ Clarifies New SAQ A Eligibility Criteria