SAQ A — это не броня: почему «безопасный» checkout всё равно течёт

SAQ A — это не броня: почему «безопасный» checkout всё равно течёт

SAQ A продают как магию: «раз вы не храните карты, значит, спите спокойно». Нет. Вы просто отдали кусок риска провайдеру и забыли, что фронт, форма и интеграция всё ещё ваши. Один кривой скрипт, подмена JS, компрометированный tag manager — и привет, утечка PAN прямо из браузера.

Главная ловушка — путать сокращённый scope с отсутствием контроля. SAQ A не защищает от:
— внедрения чужого JS в checkout;
— слива токенов через уязвимые колбэки и редиректы;
— подмены реквизитов платежа на этапе формы;
— утечки через логи, аналитики и POST-beacon'ы.

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

Минимальный чек-лист: уберите лишние third-party скрипты с checkout, закройте exfiltration через формы и URL-параметры, не тащите карточные данные в аналитику, журналируйте только то, что не убивает комплаенс, и тестируйте инъекции на каждом изменении. Документация — это ложь, логи — истина.

Если ваша схема «SAQ A = безопасно», вы не прошли аудит, а просто получили более короткий список вопросов.