PCI DSS 4.0.1 и скрипты на странице оплаты: кто их добавил и как не пропустить скиммер

Опубликовано: 27.08.2026 Обновлено: 27.08.2026 Время чтения: 18 мин

Автор и издатель: редакция «Пятого фактора».

Что должен знать владелец интернет-магазина за пять минут

С 31 марта 2025 года в PCI DSS 4.0.1 обязательны два требования — 6.4.3 и 11.6.1. Первое обязывает вести инвентарь всех скриптов, которые выполняются в браузере покупателя на странице оплаты, подтверждать, что каждый из них авторизован, и объяснять письменно, зачем он нужен. Второе — обнаруживать несанкционированные изменения этих скриптов и заголовков HTTP не реже раза в неделю и уведомлять об этом ответственных [1][3]. Требования появились в ответ на атаки типа Magecart (e-skimming), когда вредоносный код подмешивается в чек-аут и в реальном времени ворует данные карт прямо во время ввода [4][8].

Отдельный нюанс 2025 года: если оплата встроена через iframe стороннего провайдера, для упрощённой формы самооценки SAQ A теперь нужно отдельно подтвердить, что сайт «не подвержен атакам через скрипты» — либо своими средствами, либо письменным подтверждением от провайдера платёжной формы [1]. Для многих интернет-магазинов, которые считали, что встроенная форма снимает с них ответственность за скрипты, это стало неприятным сюрпризом.

Ниже — что именно нужно сделать технически, кто отвечает за какие скрипты при разных схемах интеграции оплаты и какими средствами контролировать целостность кода на практике.

В чём проблема и кому полезна статья

Современная страница оплаты — это не просто форма с полями номера карты. На ней обычно одновременно работают: скрипт самой платёжной формы, аналитика, счётчики рекламы, чат-виджет, антифрод-скрипты, скрипты тестирования (A/B), иногда — код тег-менеджера, который сам подгружает ещё несколько скриптов уже во время работы страницы [6][11]. Каждый такой скрипт — потенциальная точка входа для атаки: если скомпрометировать один из них (свой или чужой), можно незаметно перехватывать вводимые данные карты прямо в браузере покупателя, до того как они уйдут по защищённому каналу [4][9].

Материал предназначен для владельцев и техдиректоров интернет-магазинов, разработчиков e-commerce платформ, специалистов по ИБ и QSA-аудиторов, которые должны разобраться, что именно требует PCI DSS 4.0.1 от скриптов на чек-ауте, и как выстроить контроль на практике — включая случай, когда оплата принимается через встроенную форму (iframe) стороннего провайдера.

Как работает атака на странице оплаты (и почему появились новые требования)

Атаки класса Magecart и e-skimming существуют больше десяти лет. Классический сценарий: злоумышленник взламывает уязвимый компонент сайта или CMS (чаще всего — Magento и похожие платформы) и внедряет в код страницы дополнительный JavaScript, который считывает данные полей ввода карты и отправляет их на сторонний сервер [15]. В 2020 году именно так за несколько дней пострадали более двух тысяч интернет-магазинов на Magento — одна из крупнейших волн подобных атак за всю историю наблюдений [15].

Технологии маскировки таких скриптов постоянно эволюционируют. В апреле 2026 года специалисты Sansec зафиксировали новую волну Magecart-атак, в которой вредоносный код прятался внутри атрибута крошечного одно-пиксельного SVG-изображения и запускался автоматически при загрузке страницы — приём, который позволял обходить традиционные проверки внешних скриптов, поскольку сам вредоносный код формально не был «внешним файлом» [14]. Атака затронула около сотни магазинов, а похищенные данные передавались через ранее незасвеченные домены [14].

Второй канал риска — не собственный код, а «supply chain»: компрометация не сайта магазина, а стороннего сервиса, чей скрипт легитимно подключён к чек-ауту (аналитика, виджет чата, рекламный пиксель). Если атакующий взламывает поставщика такого скрипта, вредоносный код автоматически попадает на тысячи сайтов, которые этот скрипт используют, — без единого взлома самого магазина [9].

Именно эти два сценария и адресуют требования PCI SSC: 6.4.3 отвечает за управление и авторизацию скриптов, а 11.6.1 — за обнаружение несанкционированных изменений. Оба были введены ещё в PCI DSS v4.0 в 2022 году и стали обязательными к исполнению 31 марта 2025 года [3][12]. В марте 2025 года Совет дополнительно выпустил информационное приложение «Payment Page Security and Preventing E-Skimming» — отдельное разъяснение объёмом около 20 страниц о том, как технически реализовать оба требования [7][2].

Что именно требует 6.4.3: инвентарь, авторизация, целостность

Формулировка требования 6.4.3 сводится к трём обязательным элементам для каждого скрипта, который загружается и выполняется в браузере покупателя на странице оплаты [3][5]:

Метод подтверждения авторизации — должно быть понятно и документально подтверждено, что скрипт добавлен санкционированно, а не тайно кем-то из подрядчиков или в результате взлома.
Метод обеспечения целостности — техническая проверка, что содержимое скрипта не было изменено с момента авторизации.
Инвентарь с письменным обоснованием — список всех скриптов с указанием, зачем каждый из них нужен бизнесу или технически.

Требование прямо касается любого кода, который исполняется в контексте страницы оплаты: собственных бандлов, скриптов из CDN, аналитики, пикселей, виджетов чата и любых сторонних тегов [2][4]. Отдельно оговорено исключение: скрипт валидации 3D Secure не подпадает под 6.4.3, поскольку доверие к провайдеру 3DS устанавливается через отдельную юридическую и техническую проверку при подключении [5].

Практическая сложность в том, что современный чек-аут редко статичен: тег-менеджеры (например, Google Tag Manager) сами подгружают дополнительные скрипты во время работы страницы, а значит инвентарь «на бумаге» и реальный список выполняющегося в браузере кода могут расходиться [6][11]. Проверяющий (QSA) на аудите будет задавать простые вопросы: есть ли инвентарь скриптов страницы оплаты; кто его ведёт и как часто обновляет; известны ли функции и назначение каждого скрипта; как оформляется авторизация на продолжение его использования [6].

Что именно требует 11.6.1: обнаружение изменений

Требование 11.6.1 — это механизм обнаружения и оповещения, а не управления. Он должен фиксировать несанкционированное изменение содержимого скриптов и значимых для безопасности заголовков HTTP страницы оплаты — именно так, как их получает браузер конечного покупателя, а не так, как они выглядят в репозитории разработчика [10][11]. Проверка должна выполняться не реже одного раза в неделю либо с периодичностью, обоснованной целевым анализом рисков по требованию 12.3.1 [10]. В версии 4.0.1 формулировку сузили: оповещать нужно об изменениях именно значимых для безопасности заголовков, а не о любом изменении любого заголовка вообще [10].

Разница между 6.4.3 и 11.6.1 принципиальна: первое требование — превентивный контроль (авторизация и целостность до того, как скрипт попал на страницу), второе — детектирующий контроль на случай, если превентивные меры всё же были обойдены [11]. По этой причине оба требования рассматриваются PCI SSC как взаимодополняющие и обычно разбираются в одном руководстве [11][7].

Кто отвечает за скрипты при встроенной платёжной форме

Именно этот вопрос лежит в основе разъяснения PCI SSC (FAQ 1588), на которое ссылается запрос: как применяются требования, когда мерчант не принимает данные карты напрямую, а встраивает платёжную форму провайдера через iframe [1].

Совет разделил сценарии подключения оплаты на три группы, и правила для скриптов зависят от того, к какой из них относится магазин [1]:

Встроенная форма/iframe провайдера на странице магазина. Именно этот сценарий подпадает под критерий приемлемости SAQ A о «неподверженности сайта атакам через скрипты». Мерчант обязан либо сам применить техники наподобие 6.4.3/11.6.1 к странице, на которой размещён iframe, либо получить письменное подтверждение от TPSP (стороннего поставщика услуг платежей), что его решение при правильной установке уже включает защиту от атак через скрипты [1].
HTTP-редирект, meta-редирект или JS-редирект на сайт провайдера. Этот критерий на такие магазины не распространяется — покупатель физически уходит со страницы мерчанта [1].
Полностью вынесенная оплата (например, ссылка на оплату в письме, ведущая на сайт провайдера). Тоже вне действия этого конкретного критерия SAQ A [1].

Важная деталь, которую подчёркивает и сам PCI SSC, и независимые разборы этого FAQ: сама область действия требований 6.4.3 и 11.6.1 не изменилась — они как были, так и остаются обязательными для всех, кто должен их выполнять по своему уровню SAQ. Изменился только один пункт критериев приемлемости именно для упрощённой формы SAQ A: теперь мерчант с iframe должен либо доказать защищённость сам, либо предоставить подтверждение от TPSP [20][27]. Если магазин не подпадает под условия SAQ A и раньше проходил по SAQ A-EP или SAQ D, требования к скриптам для него были обязательны и до этого уточнения [20][26].

При этом ответственность внутри самого iframe и вне его физически разделена: провайдер платёжной формы отвечает за скрипты внутри своего iframe, а мерчант — за всё, что выполняется на его собственной странице, в которую этот iframe встроен, включая тег-менеджеры, аналитику, пиксели и чат-виджеты [19]. Злоумышленники неоднократно компрометировали именно окружение вокруг честно PCI-совместимого iframe, а не сам iframe — потому что снаружи защита часто отсутствовала [19].

Провайдер стороннего скрипта не считается TPSP для целей SAQ A, если единственная его функция — не связанные с платежами скрипты, которые не могут повлиять на безопасность данных держателя карты [1].

Как на практике вести инвентарь и подтверждать авторизацию

Практическая реализация 6.4.3 обычно строится на комбинации организационных и технических мер.

Организационная часть:

реестр скриптов с полями: домен/источник, назначение, ответственный подрядчик, дата последней проверки, статус авторизации;
процедура согласования при добавлении нового стороннего тега (маркетингового пикселя, чат-виджета, аналитики) — без «горячего» добавления кода через тег-менеджер в обход техотдела;
периодический пересмотр списка — новый скрипт, который никто не завёл в реестр, должен считаться поводом для расследования, а не игнорироваться [6].

Техническая часть:

Subresource Integrity (SRI) — для статичных, версионированных сторонних библиотек. Браузер получает криптографический хэш ожидаемого содержимого скрипта в атрибуте integrity; если фактический код на CDN изменился, браузер откажется его выполнять [21][23]. SRI хорошо подходит для библиотек вроде конкретной версии jQuery, но не подходит для скриптов, которые провайдер часто обновляет без предупреждения [22].
Content Security Policy (CSP), директива script-src — задаёт список разрешённых источников загрузки скриптов; загрузка кода с любого не указанного домена браузером блокируется [16][17]. CSP решает часть задачи авторизации (откуда вообще может грузиться код), но не проверяет содержимое разрешённого источника — для этого и нужен SRI в дополнение [17].
Ограничение количества скриптов и сокращение области действия — самый простой способ уменьшить риск: чем меньше скриптов реально работает на странице оплаты, тем меньше объём того, что нужно инвентаризировать, авторизовывать и мониторить [10][19]. Часть рекомендаций PCI SSC прямо предлагает выносить некритичные для оплаты скрипты в изолированные (sandboxed) iframe, отдельные от платёжной формы и родительской страницы [10].
Runtime-мониторинг — для скриптов, которые подгружаются динамически (через тег-менеджеры или сторонние асинхронные загрузчики), статичного SRI недостаточно: нужен инструмент, который отслеживает фактическое поведение скриптов в браузере пользователя в реальном времени, а не то, что было в момент код-ревью [19][11].

Важно понимать ограничение SRI, которое иногда упускают из виду: он не решает задачу инвентаризации автоматически, не покрывает динамически подгружаемые скрипты и не обнаруживает изменение поведения уже авторизованного скрипта — а именно это чаще всего использует Magecart [2].

Как на практике обнаруживать изменения (11.6.1)

Для соответствия 11.6.1 нужен механизм, который:

регулярно (минимум раз в неделю) снимает «снимок» реального содержимого скриптов и значимых для безопасности заголовков HTTP страницы оплаты — именно как их видит браузер клиента [10];
сравнивает его с эталонным/предыдущим состоянием;
оповещает ответственных сотрудников при расхождении, чтобы можно было оперативно расследовать инцидент [11].

Такой контроль можно реализовать разными способами — от специализированных коммерческих сервисов для мониторинга клиентской стороны сайта (page integrity / e-skimming protection) до собственных скриптов, которые с внешнего сервера периодически запрашивают страницу оплаты, вычисляют хэши скриптов и сверяют заголовки. Ключевое требование методологически то же, что и для инвентаря: проверять нужно то, что реально приходит в браузер конечного пользователя, а не то, что лежит в репозитории или было проверено на этапе стейджинга — потому что тег-менеджеры и сторонние загрузчики могут отдавать разный код в зависимости от условий [11][19].

Российская специфика

PCI DSS — международный отраслевой стандарт платёжных систем (Visa, Mastercard, JCB, American Express и др.), а не требование российского законодательства, но de facto является обязательным условием работы для большинства участников платёжной цепочки: банков-эквайеров, платёжных агрегаторов и мерчантов, обрабатывающих операции по картам этих систем [12][13]. Уровень проверки (полный внешний QSA-аудит, самооценка по листу SAQ или внутренний аудит с привлечением сертифицированного внутреннего специалиста ISA) зависит от годового объёма операций и определяется конкретной платёжной системой и банком-эквайером, с которым работает магазин, — точные пороговые значения могут отличаться у разных платёжных брендов и для разных категорий участников (мерчант или сервис-провайдер) [13][18]. По оценкам отраслевых источников, для интернет-эквайринга к сегменту, где обычно достаточно ежегодной самооценки SAQ без полного внешнего аудита, может относиться диапазон примерно от 20 000 до 1 млн онлайн-операций в год, но эту границу в любом случае нужно уточнять у своего эквайера [12][13].

Стоимость полноценного внешнего QSA-аудита в России в среднем начинается от нескольких сотен тысяч рублей, а сертификат подтверждения соответствия действует один год, после чего процедуру нужно проходить заново [24]. За несоблюдение применимых требований предусмотрены штрафные санкции со стороны платёжных систем и банков-эквайеров вплоть до существенных сумм и, в крайних случаях, ограничения возможности принимать платежи по картам [25][18].

Отдельная практическая особенность последних лет — доступность самих международных QSA-аудиторов для российских компаний ограничена геополитической ситуацией: часть глобальных QSA-компаний свернула работу с российскими клиентами, что усложняет прохождение полного внешнего аудита для крупных мерчантов и сервис-провайдеров, хотя формально требования стандарта не изменились [18]. Многие интернет-магазины в РФ по факту принимают оплату через российских платёжных агрегаторов (ЮKassa, CloudPayments, Tinkoff Касса, Т-Кассы и аналогичные сервисы) именно через встроенную форму или редирект — и в этом случае распределение ответственности за скрипты между магазином и агрегатором нужно уточнять индивидуально по документации конкретного провайдера, аналогично международной практике с TPSP [19]. Прямых подтверждений в открытых источниках, как именно конкретные крупные российские платёжные агрегаторы формулируют своё соответствие требованиям 6.4.3 и 11.6.1 в договорах с мерчантами, найти не удалось — это стоит уточнять непосредственно у своего эквайера или платёжного агрегатора при подключении.

Варианты реализации: что выбрать конкретному магазину

Практический выбор зависит от того, как устроена оплата на сайте:

Если оплата полностью вынесена на сайт провайдера (редирект или ссылка) — требования 6.4.3/11.6.1 к скриптам магазина в контексте критерия SAQ A по скриптам не применяются, но стоит убедиться, что сам факт редиректа реализован корректно (не JS-редиректом с уязвимостями) и что это подтверждено эквайером [1].
Если форма оплаты встроена через iframe — необходимо либо получить письменное подтверждение защищённости от провайдера формы, либо внедрить собственные меры контроля скриптов на странице, где размещён iframe [1][19]. Для небольшого магазина с несколькими статичными скриптами может быть достаточно связки CSP + SRI и регулярной ручной сверки [2]. Для сайта с тег-менеджером, множеством маркетинговых интеграций и частыми изменениями фронтенда практичнее внедрить специализированный сервис мониторинга скриптов в реальном времени, который покрывает и инвентарь, и обнаружение изменений в одном инструменте [11][19].
Если магазин самостоятельно обрабатывает данные карты (полная область действия PCI DSS, SAQ D) — требования к скриптам страницы оплаты обязательны вне зависимости от способа встраивания, и здесь обычно уже требуется системный подход: CSP на уровне инфраструктуры, CI/CD-пайплайн с проверкой хэшей первоначальных скриптов, отдельный процесс согласования сторонних тегов и регулярный аудит по всем требованиям PCI DSS, а не только 6.4.3/11.6.1 [26][6].

Практические этапы внедрения

Определить фактическую схему приёма платежей (редирект, iframe, самостоятельная обработка) и соответствующий уровень SAQ вместе с банком-эквайером или платёжным агрегатором [1][18].
Составить полный технический инвентарь скриптов, которые реально выполняются в браузере на странице оплаты — включая динамически подгружаемые через тег-менеджеры, а не только то, что видно в исходном HTML [6][11].
Для каждого скрипта зафиксировать: источник, назначение, ответственного, дату последней проверки, статус авторизации [3].
Внедрить CSP (script-src) и SRI там, где это технически применимо, и сократить число скриптов до реально необходимых [16][10].
Настроить регулярный (не реже раза в неделю) механизм сверки контрольных сумм скриптов и значимых заголовков с оповещением ответственных при расхождении [10][11].
Задокументировать процедуры и хранить историю согласований и реагирования на инциденты — это то, что запрашивает QSA на аудите [6][26].
Если оплата встроена через iframe — получить от провайдера письменное подтверждение соответствия либо параллельно реализовать собственные меры защиты страницы, на которой размещена форма [1].

Ограничения, ошибки и типичные риски

Ошибочное предположение, что iframe снимает всю ответственность. Мерчант всё равно отвечает за скрипты вне iframe — это именно та ситуация, ради которой появилось FAQ 1588 [1][19].
Инвентарь «на бумаге», не совпадающий с реальностью браузера. Тег-менеджеры и асинхронные загрузчики меняют набор исполняемого кода без изменений в репозитории — статический аудит кода это не покажет [6][11].
SRI как единственная мера. SRI не покрывает динамически подгружаемые скрипты и не ловит изменение поведения уже разрешённого скрипта — а это основной вектор атак Magecart [2].
Игнорирование supply-chain риска. Компрометация стороннего сервиса аналитики или чата может затронуть тысячи сайтов одновременно без единого взлома самого магазина [9].
Отсутствие регулярности проверки. Требование 11.6.1 задаёт минимальную периодичность (раз в неделю или по обоснованному риск-анализу) — разовая проверка при запуске сайта не соответствует требованию [10].
Маскировка вредоносного кода под безобидные элементы страницы, например изображения — актуальный пример 2026 года показывает, что традиционные проверки «внешних скриптов» не всегда обнаруживают код, спрятанный в разметке страницы [14].

Вывод

Требования 6.4.3 и 11.6.1 переводят интуитивно понятную задачу — «никто посторонний не должен трогать код на странице оплаты» — в конкретный набор проверяемых контролей: инвентарь, авторизация, целостность и регулярное обнаружение изменений. Технически задача решается комбинацией CSP, SRI, сокращения числа скриптов и runtime-мониторинга; организационно — регулярным пересмотром инвентаря и чёткой процедурой согласования новых тегов. Отдельный практический нюанс для магазинов со встроенной платёжной формой: ответственность за скрипты вне iframe провайдера остаётся на мерчанте, и это нужно либо подтвердить документально у провайдера, либо закрыть собственными средствами контроля.

Источники

[1] pcisecuritystandards.org — How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (FAQ 1588) — https://www.pcisecuritystandards.org/faqs/1588/

[2] cside.com — How to comply with PCI DSS 4.0.1 Requirement 6.4.3: a practical checklist — https://cside.com/blog/how-to-comply-with-pci-dss-6-4-3

[3] blog.rsisecurity.com — PCI DSS Requirements: Breakdown of 6.4.3 and 11.6.1 — https://blog.rsisecurity.com/breakdown-of-the-pci-requirements-643-1161/

[4] foregenix.com — Introduction of new requirements (6.4.3 and 11.6.1) for PCI DSS v4.0 — https://www.foregenix.com/blog/introduction-of-new-requirements-6.4.3-and-11.6.1-for-pci-dss-v4.0

[5] docs.adyen.com — Script security for ecommerce — https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security

[6] sikich.com — Preparing for PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 — https://www.sikich.com/insight/preparing-for-pci-dss-v4-0-1-requirements-6-4-3-and-11-6-1/

[7] blog.pcisecuritystandards.org — New Information Supplement: Payment Page Security and Preventing E-Skimming — https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming

[8] schellman.com — Fortifying the Digital Checkout: Payment Page Security in E-Commerce — https://www.schellman.com/blog/pci-compliance/payment-page-security-in-e-commerce

[9] blog.basistheory.com — Embracing PCI 4.0 Requirements — https://blog.basistheory.com/embracing-pci-4.0-requirements

[10] akati.com — Securing Payment Pages Under PCI — https://www.akati.com/insights-blog/securing-payment-pages-under-pci

[11] visualping.io — PCI DSS 4.0.1 Section 11.6.1: How Website Change Detection Supports Compliance — https://visualping.io/blog/pci-compliance-section-1161

[12] pay.yandex.ru — PCI DSS: что это, требования стандарта, уровни, сертификация — https://pay.yandex.ru/blog/articles/chto-takoe-standart-pci-dss

[13] www.infosec.ru — PCI DSS сертификация: полное руководство — https://www.infosec.ru/glavnye-temy/pci-dss-sertifikatsiya-polnoe-rukovodstvo/

[14] securitylab.ru — Один лишний пиксель и пустая карта: как хакеры воруют деньги через невидимые картинки — https://www.securitylab.ru/news/571348.php

[15] xakep.ru — Магазины на базе Magento подверглись самой масштабной атаке с 2015 года — https://xakep.ru/2020/09/15/magento-under-attack-2/

[16] developer.mozilla.org — Content-Security-Policy: script-src directive — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src

[17] content-security-policy.com — PCI DSS 4.0 and Content Security Policy (CSP) — https://content-security-policy.com/examples/pci-dss/

[18] garda.ai — Стандарт PCI DSS – российские реалии внедрения — https://garda.ai/blog/articles/standart-pci-dss-rossiyskie-realii-vnedreniya

[19] feroot.com — Meeting SAQ-A-EP Requirements 6.4.3 and 11.6.1 on Hosted Payment Pages — https://www.feroot.com/blog/saq-a-ep-requirements-6-4-3-11-6-1/

[20] trustedsec.com — The Hidden Trap in the PCI DSS SAQ A Changes — https://trustedsec.com/blog/the-hidden-trap-in-the-pci-dss-saq-a-changes

[21] en.wikipedia.org — Subresource Integrity — https://en.wikipedia.org/wiki/Subresource_Integrity

[22] medium.com — Subresource Integrity Checking and Content Security Policies — https://medium.com/@clare.lindley/subresource-integrity-checking-and-content-security-policies-4160ae5c0428

[23] pcipolicies.com — How to Comply with PCI DSS Requirement 6.4.3 — https://pcipolicies.com/blogs/news/how-to-comply-with-the-new-pci-dss-requirement-6-4-3

[24] anti-malware.ru — Сертификации в ИБ: российские и международные — что выбрать в 2026 году — https://www.anti-malware.ru/analytics/Technology_Analysis/Certifications-in-information-security

[25] itglobal.com — PCI DSS сертификация: подготовка к проверке на соответствие стандарту — https://itglobal.com/ru-ru/services/info-security/conformity-assessment/certification-pci-dss/

[26] feroot.com — SAQ A-EP: Top 5 Actions Merchants Must Take to Comply with PCI DSS 4 Requirements 6.4.3 and 11.6.1 — https://www.feroot.com/blog/saq-a-ep-top-5-actions-merchants-must-take-to-comply-with-pci-dss-4-requirements-6-4-3-and-11-6-1-by-march-31-2025/

[27] hyperproof.io — PCI DSS 4.0 Update: New SAQ A Eligibility Criteria — https://hyperproof.io/resource/pci-dss-4-0-update-new-saq-a-eligibility-criteria/