Защита API в финтехе и e-commerce: разбор сценариев атак и решений
В финтехе и e-commerce API — это и есть продукт: мобильный банк, открытый банкинг, платёжный шлюз, корзина, цены, остатки, личный кабинет. Чем больше бизнес-логики уходит в API, тем больше атакующих целятся именно в них, а не в «фасадный» сайт. При этом классический сетевой периметр и сигнатурный WAF видят такие атаки плохо: формально запросы валидны, ломается бизнес-логика и авторизация на уровне объектов. **Если коротко:** защита API — это не «ещё одно правило в WAF», а отдельный контур. Нужно знать все свои API (включая забытые и теневые), контролировать авторизацию на уровне объектов и функций, ограничивать частоту и аномальное поведение, отличать ботов от людей и закрывать утечку чувствительных данных (PII, платёжные реквизиты). Ниже — типовые сценарии атак, чем их закрывают (WAAP и API Security) и по каким критериям выбирать решение. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге WAF и защиты API](/rating/waf-api-security).
API и веб-периметр нужно защищать на уровне запросов
Для WAF и API Security важны сценарии трафика, бизнес-методы, боты и признаки злоупотреблений на границе приложения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Почему API в финтехе и e-commerce — главная мишень
API в этих отраслях обрабатывают деньги и персональные данные, а значит цена успешной атаки измеряется прямыми потерями, а не просто дефейсом. Несколько причин, почему именно API становятся точкой входа:
- **Бизнес-логика переехала в API.** Мобильные приложения, партнёрские интеграции, открытый банкинг и headless-витрины общаются с бэкендом по REST и GraphQL. Любой дефект авторизации в эндпоинте — это прямой доступ к чужим деньгам или данным. - **Запросы выглядят легитимными.** Атаки на API чаще эксплуатируют логику, а не «классические» инъекции: подмена идентификатора объекта, перебор, злоупотребление функцией. Сигнатуры здесь почти не помогают. - **Поверхность атаки растёт быстрее, чем её инвентаризируют.** Версии `v1/v2`, тестовые и «временные» эндпоинты, документация Swagger в проде — частые причины утечек через теневые (shadow) и забытые (zombie) API. - **Высокая автоматизация атак.** Credential stuffing, парсинг цен и остатков, фрод-сценарии выполняются ботами на скорости, недостижимой для человека.
Сценарии атак на API и чем их закрывать
Ниже — ориентир по типовым сценариям для финтеха и e-commerce и по тому, какой класс контроля их закрывает. Это не сравнение вендоров: места, баллы и подтверждённые сигналы смотрите в [рейтинге категории](/rating/waf-api-security). Нумерация сценариев опирается на классификацию [OWASP API Security Top 10](https://owasp.org/www-project-api-security/).
| Сценарий атаки | Что происходит | Чем закрывать |
|---|---|---|
| BOLA / нарушение авторизации объектов | Подмена ID в запросе даёт доступ к чужому счёту, заказу, профилю | API Security: контроль авторизации на уровне объектов, обнаружение аномалий доступа |
| Credential stuffing | Перебор украденных логинов/паролей по эндпоинту авторизации | Bot management, rate limiting, MFA-сигналы, проверка репутации источника |
| Парсинг цен и остатков | Боты выкачивают каталог, цены и наличие для конкурентов и арбитража | Поведенческий анализ, ограничение частоты, разметка автоматизированного трафика |
| Фрод и злоупотребление бизнес-логикой | Эксплуатация промокодов, кэшбэка, лимитов, гонки запросов (race conditions) | Контроль бизнес-логики, лимиты на функции, корреляция сессий |
| Утечка PII и платёжных данных | Эндпоинт отдаёт лишние поля или избыточный объём данных | Инспекция ответов, маскирование/детект чувствительных полей, контроль над-выдачи (excessive data exposure) |
| Теневые и забытые API | Атака идёт через незадокументированный или устаревший эндпоинт | Auto-discovery API, инвентаризация, контроль версий и схем |
Чем WAAP и API Security отличаются от классического WAF
Классический WAF защищает веб-приложение от инъекций и известных уязвимостей по сигнатурам. Для API этого мало: ключевые угрозы лежат в логике и авторизации, которые сигнатура не описывает. Поэтому защита API строится на нескольких слоях:
- **Discovery и инвентаризация.** Нельзя защитить то, чего не знаешь. Автоматическое обнаружение эндпоинтов, версий и схем закрывает теневые и забытые API. - **Контроль авторизации (BOLA/BFLA).** Анализ того, кто и к каким объектам и функциям обращается, выявление доступа «не к своему». - **Bot management и rate limiting.** Отделение автоматизированного трафика от человеческого: credential stuffing, парсинг, перебор. - **Контроль данных в ответах.** Детект и маскирование PII и платёжных реквизитов, выявление избыточной выдачи полей. - **Поведенческая аналитика.** Базовая линия нормального поведения и срабатывание на аномалии — то, что сигнатуры пропускают.
> WAAP (Web Application and API Protection) — это эволюция WAF: тот же контур плюс > защита API, bot management и часто anti-DDoS. Подробнее о разнице — в статье > [WAF vs WAAP](/research/waf-vs-waap-zashchita-api).
Распределение типов API-инцидентов в финтехе и e-commerce
Усреднённая редакционная оценка структуры инцидентов на основе классификации OWASP API Security Top 10 и открытых данных. Это не статистика конкретной организации и не заменяет аудит вашего API-ландшафта.
Чек-лист защиты API в финтехе и e-commerce
Внедрение защиты API: 6 шагов
-
01
Discovery и инвентаризация
Соберите полную карту API: эндпоинты, версии, схемы, авторы, чувствительные данные. Найдите теневые и забытые API.
-
02
Приоритизация рисков
Ранжируйте эндпоинты по критичности: оплата, авторизация, доступ к PII — в первую очередь.
-
03
Базовые контроли
Включите rate limiting, bot management и контроль авторизации в режиме мониторинга, без блокировок.
-
04
Калибровка и базовая линия
Накопите профиль нормального трафика, отстройте поведенческую аналитику, уберите ложные срабатывания.
-
05
Перевод в блокировку
Поэтапно включайте блокирующие политики на критичных эндпоинтах, контролируя влияние на легитимные интеграции.
-
06
Мониторинг и развитие
Регулярная переинвентаризация API, обновление политик под новые версии и сценарии фрода.
Комплаенс: PCI DSS и 152-ФЗ кратко
Защита API в финтехе и e-commerce почти всегда пересекается с регуляторными требованиями. Два ключевых ориентира:
- **PCI DSS** — стандарт [PCI Security Standards Council](https://www.pcisecuritystandards.org/) для всех, кто обрабатывает, передаёт или хранит данные платёжных карт. Требует защиты передаваемых данных, контроля доступа, мониторинга и тестирования — API-эндпоинты, работающие с платёжными реквизитами, попадают в область оценки напрямую. - **152-ФЗ «О персональных данных»** — задаёт требования к защите ПДн. Личные кабинеты, профили и эндпоинты, отдающие персональные данные, должны быть защищены от утечек и избыточной выдачи; уровень защищённости определяется по приказам регуляторов.
Для значимых объектов и госсегмента дополнительно учитываются требования к доверенным СЗИ: проверяйте статус решения в [реестре отечественного ПО](https://reestr.digital.gov.ru/) и [реестре сертифицированных СЗИ ФСТЭК](https://reestr.fstec.ru/).
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом WAF и защиты API](/rating/waf-api-security): здесь — сценарии и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались со сценариями и критериями — переходите к сравнению поставщиков: **[рейтинг WAF и защиты API →](/rating/waf-api-security)**. Полезно прочитать рядом: [WAF vs WAAP: что такое защита API](/research/waf-vs-waap-zashchita-api), [российские WAF 2026: чем заменить F5, Imperva и Cloudflare](/research/rossiyskie-waf-2026-zamena-f5-imperva-cloudflare) и [как выбрать WAF: чек-лист](/research/kak-vybrat-waf-cheklist).
Частые вопросы
Чем защита API отличается от обычного WAF?
WAF ловит известные веб-атаки по сигнатурам (инъекции, XSS). Ключевые угрозы для API — это нарушение авторизации на уровне объектов и функций, злоупотребление бизнес-логикой, парсинг и фрод. Их сигнатура не описывает, поэтому нужен отдельный контур API Security с discovery, контролем авторизации, bot management и поведенческой аналитикой.
Что такое BOLA и почему это главная угроза для финтеха?
BOLA (Broken Object Level Authorization) — это когда подмена идентификатора объекта в запросе даёт доступ к чужим данным: счёту, заказу, профилю. Эндпоинт технически исправен, но не проверяет, что объект принадлежит запрашивающему. Для финтеха это прямой путь к чужим деньгам и данным, поэтому контроль авторизации объектов — приоритет №1.
Достаточно ли WAAP, чтобы закрыть все сценарии атак на API?
WAAP закрывает большую часть: классические веб-атаки, bot management, rate limiting, базовый API-контроль и часто anti-DDoS. Но глубокий контроль бизнес-логики, авторизации объектов и инвентаризацию теневых API нередко обеспечивают специализированные модули API Security. На практике это выбор между «всё в одном» и связкой решений — зависит от зрелости и масштаба API-ландшафта.
Защищает ли решение GraphQL так же, как REST?
Не всегда. GraphQL допускает сложные вложенные запросы и единый эндпоинт, что меняет модель защиты: важны контроль глубины и сложности запросов, лимиты и анализ схемы. Если у вас есть GraphQL, проверяйте поддержку явно — не все решения разбирают её наравне с REST.
Как комплаенс PCI DSS и 152-ФЗ влияет на выбор решения?
Если API работают с платёжными картами, эндпоинты попадают в область PCI DSS — нужны защита передачи, контроль доступа и мониторинг. Если отдают персональные данные — действует 152-ФЗ. Для значимых объектов и госсегмента добавляются требования к доверенным СЗИ: смотрите реестр отечественного ПО и реестр сертифицированных СЗИ ФСТЭК.
Где сравнить конкретных вендоров между собой?
В рейтинге WAF и защиты API — там компании ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
В финтехе и e-commerce API — это и есть продукт: мобильный банк, открытый банкинг, платёжный шлюз, корзина, цены, остатки, личный кабинет. Чем больше бизнес-логики уходит в API, тем больше атакующих целятся именно в них, а не в «фасадный» сайт. При этом классический сетевой периметр и сигнатурный WAF видят такие атаки плохо: формально запросы валидны, ломается бизнес-логика и авторизация на уровне объектов. **Если коротко:** защита API — это не «ещё одно правило в WAF», а отдельный контур. Нужно знать все свои API (включая забытые и теневые), контролировать авторизацию на уровне объектов и функций, ограничивать частоту и аномальное поведение, отличать ботов от людей и закрывать утечку чувствительных данных (PII, платёжные реквизиты). Ниже — типовые сценарии атак, чем их закрывают (WAAP и API Security) и по каким критериям выбирать решение. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге WAF и защиты API](/rating/waf-api-security).