Як карткові дані можуть вкрасти ще до платежу: що потрібно знати

Додайте Finance.ua до вибраних джерел Google

Web skimming, або e-skimming, — це перехоплення карткових та інших персональних даних під час взаємодії покупця із сайтом. Замість фізичної накладки на банкомат зловмисники використовують програмний код.

Замовлення оплачене, гроші надійшли, покупець отримав підтвердження. Для магазину все виглядає нормально. Однак реквізити картки могли потрапити до зловмисників ще під час введення — через шкідливий код на сайті. Така атака називається web skimming.

Про це пише WayForPay, ми вибрали основне.

Як дані викрадають

За поясненням американського агентства кібербезпеки CISA, такий код може потрапити на сайт через вразливість платформи, викрадені облікові дані адміністратора або скомпрометований сторонній сервіс. Інформація перехоплюється під час введення та передається на сервер нападників.

Уявімо магазин, у якому через застарілий плагін зловмисник змінив сторінку оформлення замовлення. Перед справжньою оплатою покупцеві показують підроблену форму. Після введення реквізитів вона повідомляє про «помилку» та відкриває справжню платіжну сторінку. Людина повторює дію, оплачує покупку, але перша форма вже передала дані стороннім.

Місце для вашої реклами

Це ілюстративний сценарій, а не опис інциденту. Підроблені вбудовані форми та спливні вікна, які імітують справжній checkout, описані у звіті Visa про загрози.

Інший варіант — непомітне копіювання даних із полів, до яких шкідливий скрипт має доступ. В обох випадках успішна оплата не доводить, що реквізити не були викрадені раніше.

Реальний кейс: усі думали, що безпекою займається хтось інший

Показовий випадок описав британський регулятор ICO щодо магазину Direct Clothing. У серпні 2021 року покупець повідомив про шахрайські операції з карткою після використання сайту компанії.

Перевірка виявила шкідливий код, який дозволяв зловмиснику отримувати реквізити карток покупців. Доступ до сайту він здобув через вразливість WordPress. Однак на момент інциденту сайт мав стільки невиправлених вразливостей, що визначити, яку саме використав нападник, не вдалося.

Важлива деталь: компанія вважала, що за безпеку й обслуговування сайту відповідає IT-підрядник, проте фактично це було не так.

Для підприємця цей кейс починається з простого запитання: хто саме оновлює плагіни, погоджує зміни на сторінці оплати та реагує на підозрілу активність? Відповідь має бути закріплена в домовленостях із підрядником. Формулювання «сайтом займається розробник» недостатньо: створення магазину та його подальший захист — різні завдання.

Що показують перевірки платіжних сторінок

За результатами SecurityMetrics за 2026 рік, у 67% перевірок платіжних сторінок сервісом Shopping Cart Inspect виявили проблеми різного рівня небезпеки — від потенційних слабких місць до ознак викрадення даних.

Це не означає, що 67% інтернет-магазинів зламані. Йдеться про конкретну вибірку перевірок, яка не представляє весь ринок. Серед усіх виявлених проблем 4% належали до категорії malicious — зі свідченнями крадіжки карткових даних. Решта були підозрілими або потенційно небезпечними.

Перевіряти варто не лише підтверджені витоки, а й умови для їх виникнення. Застарілий компонент або неконтрольований скрипт ще не доводить наявності атаки, але потребує уваги до того, як його використовує сайт.

Що допомагає зменшити ризики

Один із практичних кроків — організувати оплату так, щоб магазин не збирав карткові реквізити власними формами.

Наприклад, WayForPay пропонує платіжну сторінку, на якій покупець вводить реквізити, та платіжний віджет. Віджет відкривається поверх сторінки магазину, але, за документацією, фактично оплата відбувається на стороні WayForPay. Це дозволяє використовувати готову платіжну форму замість самостійної реалізації збору карткових даних.

Ключове значення має правильне підключення. Розробник повинен перевірити, що реквізити не збираються додатковими полями магазину, не потрапляють у його журнали чи інструменти аналітики, а платіжний компонент завантажується з офіційного джерела.