На связи Лука Сафонов, бизнес-партнер по инновационному развитию компании «Гарда».
Финансово-банковский сектор в России и странах СНГ вошел в цифровую эпоху позже многих зарубежных рынков, но этот старт дал практическое преимущество. Инфраструктуру строили сразу под высокие требования к доступности, устойчивости и жесткий контроль регуляторов. Банки с первых лет работы учитывали требования ЦБ, платежных систем и отраслевых стандартов. Благодаря этому крупномасштабные утечки данных и прямые кражи денег случаются реже, чем в других юрисдикциях, и чаще связаны с нетиповыми или целевыми сценариями.
Однако это не делает финтех-сектор менее восприимчивым к атакам. Они происходят достаточно регулярно. Просто в силу высоких репутационных и регуляторных рисков информация об инцидентах редко становится публичной.
И хотя атаки на цифровые сервисы держатся в секрете, совокупный тренд говорит однозначно: давление на финансовый сектор растет. Даже самые зрелые digital-экос��стемы сегодня работают в условиях беспрецедентного роста киберугроз.
В 2025 году общее число киберинцидентов на российские компании выросло на 42%, и почти каждая четвертая атака имела серьезные последствия для бизнеса. Финансовый сектор при этом остается в числе пяти наиболее атакуемых отраслей. Несмотря на свою зрелость, он привлекает злоумышленников своей ценностью: здесь сосредоточены данные, деньги и критически важные сервисы.
Если раньше атаки были направлены на кражу, то теперь хакеры все чаще выбирают более разрушительную тактику: более 70% критических инцидентов в прошлом году были связаны с полным выводом IT-инфраструктуры из строя ради вымогательства или саботажа. Средний выкуп за расшифровку данных колебался от 4 до 40 млн рублей, а в отдельных случаях достигал 0,5 млрд. Почти половина всех атак вызвала сбои в работе ИТ-систем, а 64% инцидентов сопровождались утечками данных. По прогнозам экспертов, в 2026 году число успешных атак вырастет еще на 30-35%.
Справедливости ради успех большинства атак связан не с гениальными хакерскими трюками, а с банальными ошибками в архитектуре цифровых сервисов, связанными, зачастую со спешкой при выводе продуктов на рынок. Бизнес придумывает новый сервис, разработка торопится запустить его раньше конкурентов, а вопросы безопасности отходят на второй план — особенно если их проверяют перед релизом, а не в процессе разработки. В поспешно выпущенном продукте остаются архитектурные огрехи и непроверенные сценарии работы, что оборачивается внеплановыми остановками сервиса, срочными релизами «в ночь» и потерей фокуса у продуктовых команд.
Такая логика характерна не только для финтеха. Во многих отраслях расчет прост: потенциальная прибыль перекрывает возможные потери от инцидента. Это не столько техническое, сколько управленческое решение: какие сроки считать допустимыми, какие риски — приемлемыми, а какие проблемы — можно «решить потом».
Для организации атаки хакерам не нужны уникальные навыки: автоматизированные инструменты доступны в даркнете за символическую плату, а рынок киберпреступности давно превратился в отлаженный бизнес с подписками, техподдержкой и даже собственными конференциями.
В этой статье разберу основные точки входа, через которые сегодня атакуют финтех, и расскажу об инструментах, позволяющих грамотно выстраивать сетевую безопасность цифровых сервисов.
Почему фронтенд считают слепой зоной для сетевой безопасности?
Современная атака редко начинается с прямого взлома ядра системы или приложения. Чаще злоумышленник движется по вполне предсказуемой цепочке. Сначала злоумышленник ищет слабое место. Например, личный кабинет клиента. Допустим, банк использует чат поддержки, который загружает внешний JavaScript-код. Если этот код скомпрометирован, то скрипт получает доступ ко всему, что происходит на странице: полям ввода, кнопкам, токенам авторизации.
Встречаются и логические ошибки. Например, отсутствует проверка прав на просмотр чужих данных или нет ограничений на частоту запросов, то атакующий злоумышленник быстро находит способ нанести ущерб. В итоге добирается до самого ценного — платежного контура.
Время присутствия вредоносного кода почти всегда измеряется неделями и месяцами. Тут приходит в голову недавний инцидент в одном из крупнейших банков США, когда в интернет-магазине для сотрудников банка обнаружили внедренный скрипт-сниффер. Он перехватывал логины, пароли и данные банковских карт прямо со страниц. Скрипт проработал около 45 дней, пока его не обнаружили.
Как злоумышленники используют уязвимости API при организации атак
По оценкам аналитиков, эксплуатация уязвимостей API станет одной из ключевых угроз для финансового сектора в 2026 году. И это не случайность: современные веб-приложения уже давно перестали быть монолитными страницами. Сегодня даже личный кабинет банка — это, зачастую SPA-приложение (single page application), которое полагается на API для отображения баланса, инициации переводов или проверки истории операций. Иными словами, вовремя атак на веб-приложение сегодня, как правило, включает атаку на его API. И чем больше сервисов компания выпускает, тем шире становится эта поверхность атаки.
Тренд подтверждает наше совместное исследование с TAdviser, согласно данным которого почти 70% российских компаний сталкивались с атаками на веб-приложения в 2025 году, а у 35% такие инциденты происходили еженедельно или чаще. При этом 80% респондентов отмечают рост потребности в защите именно API.
Почему атакуют API? Потому что если в них есть уязвимости, то используя эти «дыры», злоумышленник получает прямой доступ к данным и бизнес-логике, минуя все защитные механизмы пользовательских интерфейсов. Причем для этого, как я уже сказал, часто хватает простой логической ��шибки. Например, в одном из российских сервисов отсутствовала проверка прав доступа на уровне объектов (BOLA) в GraphQL API. Атакующие получили данные более чем 10 000 клиентов (включая балансы и историю транзакций), просто подменив userID в запросе.
Другой типичный сценарий — отсутствие лимитов на запросы. В одном из инцидентов API для отправки SMS-уведомлений не имел защиты от брутфорса. В итоге за ночь бот отправил сотни тысяч OTP-запросов, и компания потеряла 28 млн рублей. Если ограничения настраиваются вручную, вероятность такого сценария резко возрастает.
Печально, что состояние API в инфраструктурах часто оставляет желать лучшего. Во-первых, зомби-API (брошенные или устаревшие интерфейсы) продолжают работать в облаке, оставаясь незащищенными. Во-вторых, сторонние зависимости тянут за собой цепочку уязвимостей. В-третьих, плохая документация и отсутствие инвентаризации.
Более того, массовый переход к модели API-first привел к тому, что интерфейсы появляются быстрее, чем осмысленная архитектура и контроль. На практике встречаются случаи, когда банк или сервис можно вывести из строя простым некорректным запросом. API падает — и тянет за собой веб-интерфейсы и личные кабинеты, из-за чего клиенты не могут войти в аккаунты, оплатить услуги или перевести деньги в течение нескольких часов.
Хуже всего, что владельцы систем, как правило, не знают точного числа своих API. По данным некоторых исследований, компании в среднем имеют на 30% больше API, чем задокументировано. Эти «теневые» интерфейсы становятся приоритетной целью для атакующих. Проблему усугубляет слабое распространение практик безопасной разработки API. OWASP API Top 10 до сих пор остается нишевым знанием, а системный подход к защите применяется редко. Мешают нехватка экспертизы, инерция процессов и ориентация на поддержку устаревших решений. Все это приводит к накоплению уязвимостей и росту стоимости их устранения со временем.
Атаки на цепочки поставок: хакеры используют доверие как уязвимость
Цифровые сервисы редко создаются в изоляции. Банки и финтех-компании вынуждены прибегать к услугам на внешних поставщиков (облачных платформ и SaaS-решений, аутсорсинговых команд или open-source библиотек). Эта зависимость создает новую, системную точку входа — цепочку поставок.
В 2025 году в 10 российских финансовых организациях произошли инциденты с вирусами-шифровальщиками — и в большинстве случаев проникновение произошло именно через подрядчиков. Это лишний раз доказывает, что даже при идеальной защите собственного периметра достаточно одной уязвимости у партнера, чтобы скомпрометировать всю экосистему.
Яркий пример: в 2024 году ИТ-поставщик, обслуживающий сотни банков в США, подвергся атаке через уязвимость в межсетевом экране. Злоумышленники получили доступ к персональным и финансовым данным сотен тысяч клиентов. Инцидент затронул как минимум 74 финансовые организации, ни одна из которых не была взломана напрямую (компрометация произошла исключительно через цепочку поставок).
Ситуация усугубляется тем, что многие организации не имеют четких требований к информационной безопасности своих подрядчиков. Отсутствие обязательных стандартов, недостаточный контроль за обновлениями ПО, использование общих учетных записей или CDN без проверки целостности — все это создает векторы компрометации, которые могут годами оставаться незамеченными.
Особенно уязвимы компании, активно внедряющие искусственный интеллект. По последним данным, более 25% финтех-организаций уже сталкивались с инцидентами, связанными с атаками на ИИ-системы. Часто такие системы строятся на внешних LLM, open-source библиотеках или генеративных моделях, чья безопасность не проверяется должным образом. Так, буквально одна утечка через prompt injection может привести к раскрытию конфиденциальных данных клиентов или нарушению работы критических сервисов.
Почему традиционные меры защиты не всегда работают — и что с этим делать
Традиционные меры защиты зачастую оказываются бессильны перед ошибками бизнес-логики приложения. Когда на уровне протокола запрос выглядит легитимным, то автоматизированные инструменты, не понимая контекста, не всегда могут обнаружить проблему.
Чтобы гарантированно защитить цифровые сервисы от нападок кибермошенников, необходимо сместить фокус с поиска «дыр» на управление рисками на уровне архитектуры и процессов.
Рекомендую начинать с базовых мер безопасности.
Важно провести инвентаризацию сервисов и API. Невозможно оценивать риски, не зная точно, какие веб-сервисы и API работают в инфраструктуре, какие данные через них проходят и кто за них отвечает. Компании, инвестирующие время в подобные упражнения, обычно сталкиваются с меньшим числом аварий или проще их локализуют.
Желательно встроить политики безопасности в процесс разработки. Проверка кода, ограничение доступов, контроль ошибок и установка лимитов на запросы — все это минимальный набор действий, который снижает риски массовых атак.
Подводя итоги, отмечу, что восприимчивость цифровых сервисов к атакам — это не столько вопрос отдельных технологий, сколько качество управленческих решений и дисциплина на всех уровнях. Такая основа позволяет эффективнее использовать и технические средства. Например, снижать нагрузку на команды и уменьшать число инцидентов, вызванных тривиальными ошибками или автоматизированными атаками за счет внедрение решений класса WAF для фильтрации очевидного мусора и аномалий в HTTP-трафике.
