SAQ A не броня: почему «минимум PCI» не спасает ваши данные

SAQ A не броня: почему «минимум PCI» не спасает ваши данные

SAQ A — это не магический щит, а бумажка о том, что вы отдали ввод карты на сторону. И всё, на этом сказка про безопасность заканчивается. Если у вас на странице живёт кривой JS, лишние теги аналитики, редиректы через десятые руки и «временно» вставленный виджет — вы уже не в стерильной зоне.

Типовые дыры всегда одни и те же:
— подмена реквизитов формы через XSS или скомпрометированный tag manager;
— утекающие referrer’ы, order_id и customer data в сторонние скрипты;
— webhook’и без подписи и идемпотентности, где один дубль превращается в хаос;
— админки и логи, где номер карты «случайно» всплыл в маске не того формата.

Главная иллюзия — думать, что раз PAN не храните, то и атаковать нечего. Атакуют не хранилище, атакуют точку ввода, браузер клиента и вашу связку фронт + провайдер. Документация любит рисовать безопасную витрину, логи обычно показывают костыль на костыле и финтехом погоняет.

Проверка простая: инвентаризируйте все сторонние скрипты, режьте права на фронте, подпишите вебхуки, запретите хранение чувствительных полей в логах, прогоняйте page integrity checks и отдельный аудит формы оплаты. Идемпотентность или смерть.