Предисловие
Прочность банковской системы определяется не одними отчётами для проверяющих. Её основа — это код и «железо». Если они не менялись пятнадцать лет, даже самые строгие правила становятся пустой бумажкой.
Мы провели внешний технический анализ публичных интерфейсов (фронтенд, API, заголовки) ряда региональных банков. Цель — оценить не «красоту» дизайна, а возраст и состояние технологического стека как индикатор глубинных архитектурных проблем.
Ключевой вывод: во многих случаях мы обнаружили работающие в продакшене 2026 года технологии, вышедшие из поддержки ещё в нулевых: HTML-фреймы, jQuery 1.x с методом .live(), устаревшие версии PHP и веб-серверов. Это не вопрос «устаревшего дизайна» — это прямое указание на критический технический долг, который создаёт неприемлемые риски для бизнеса.
Устаревшая архитектура
Современный веб — это динамичные веб-приложения, адаптивные интерфейсы и интерактивные элементы. Интерфейсы, которые мы обнаружили, выглядят иначе: статичные таблицы (<table> для вёрстки), всплывающие окна через window.open(), навигация через перезагрузку страницы. Это не «консервативный дизайн». Это технологии, которые перестали быть актуальными 15 лет назад. И если так выглядит «лицо» системы, можно лишь догадываться, что происходит «под капотом».
<frameset>
Первое что мы обнаружили это крайне устаревшая архитектура Front-end части, речь идет не о фреймворках, а о старых версиях самого HTML, ниже показали пример кода, который использовался в продакшене одного из банков.
<frameset rows="33%,62%,5%" border="0">
<frame src="base.htm">
<frame src="up.htm">
</frameset><frameset> был признан устаревшим и не рекомендуется для использования в современной разработке. Фреймы как правило подвержены атаке типа Clickjacking, что для финансового сектора максимально критично. Также поисковые роботы плохо индексируют такие сайты, что может сказаться на потенциальных клиентах и SEO оптимизации.
Отсутствие адаптивности
6 из 10 банков, которые мы проверили, имели проблемы с отображением контента на мобильных устройствах. Это связано не с нежеланием сделать «мобильную версию», а с фундаментальными архитектурными ограничениями их систем.
Основная причина — использование табличной вёрстки (<table> для layout) и абсолютного позиционирования — методов, доминировавших до массового перехода на мобильный интернет (~2010-2012 гг.). Такой код физически не может адаптироваться под разные размеры экранов без полной переписи.
Эта проблема создает определенные бизнес риски для всех организаций, не только финансовых:
Потеря клиентов: Более 60% трафика сейчас идёт со смартфонов. Нечитаемый интерфейс = отказ от услуги.
Блокировка развития: Невозможно запустить современное мобильное приложение или PWA (Progressive Web App), так как нет адаптивного API и компонентов.
Репутационный ущерб: Для пользователя «ломающийся» сайт — признак ненадёжности и неуважения.
Однако, даже если с мобильной вёрсткой всё в порядке, это не гарантирует безопасность. Следующий слой проблем — устаревшие JavaScript-библиотеки и зависимости, которые мы обнаружили в коде большинства проверенных систем. Именно они зачастую становятся точкой входа для реальных атак.
Устаревшие библиотеки, потенциальные уязвимости
Эта проблема одна из самых распространенных в региональных банках Российской Федерации. 9 из 10 банков проверенных нами имели очень старый набор технологий, который может иметь кучу уязвимостей. Ниже привели ряд самые яркие примеры техдолга
---------------- | Банк X | Банк Y | Банк Z |
Front-end | jQuery 1.8.3 (2012). Содержит XSS-уязвимость CVE-2015-9251. | jQuery 2.1.0 + UI 1.10.3 (оба 2013). Конфликтующий стек с уязвимостями (CVE-2015-9251, CVE-2016-7103). | HTML 4.0 (1999), . |
Back-end | PHP 5.1.2 (2005). Катастрофа. 15+ лет без патчей. Открыт для RCE и SQL-инъекций. | Java 7, вышла в 2011 году spring framework: 3.1, вышел в 2011 году | Отсутствует |
Сервер | Nginx (как прокси) | Nginx (как балансировщик) | Nginx (как прокси) |
📊 Риск | Банк максимально уязвим к большинству атакам, в результате чего могут пострадть клиенты | Иллюзия контроля при растущих затратах и скрытых уязвимостях. | Бизнес заперт в прошлом. Развитие невозможно без полной перезагрузки. |
Представленные кейсы — не исключения, а системное явление. Накопление техдолга в региональном финтехе достигло точки, где безопасность и бизнес-развитие становятся взаимоисключающими понятиями. В большинстве проектов имеются костыли, создается иллюзия, что всё работает и всё хорошо, но это не так.
Публичный localhost
Анализ DNS-записей выявил не просто разрозненную архитектуру, а критические ошибки конфигурации, которые не должны существовать в принципе. Самым вопиющим примером стал публичный субдомен localhost.
localhost— это зарезервированное сетевое имя для обращения компьютера к самому себе. Его вынос в публичное DNS — грубейшее нарушение базовых принципов сетевой безопасности и администрирования.Прямое указание на низкую квалификацию или полное отсутствие контроля. Такая ошибка не появляется случайно в продакшене. Она говорит о том, что процессы code review, тестирования и выкладки изменений в инфраструктуру либо отсутствуют, либо полностью провалены.
Существует ли выход из этой проблемы?
Когда техдолг становится системным, классические подходы — «нанять больше разработчиков» или «выделить год на переписывание» — не работают. Первые утонут в поддержке легаси, второй проект почти наверняка провалится из-за неподъёмного объёма и рисков. Отраслевая практика показывает, что единственный устойчивый путь — стратегия управляемой эрозии legacy. Её можно свести к трём принципам.
Что болит больше всего?
Откажитесь от глобального аудита. За 1-2 недели найдите один модуль, где сходятся: операционная боль (чаще всего ломается), критический риск (работает наPHP 5.1/jQuery 1.x) и возможность изоляции. Всё остальное — шум. Первый шаг — всегда один.Не меняем всё и сразу!
Не переписывайте. Замещайте. Постройте новый микросервис рядом со старым кодом. Через feature flag или роутер плавно переключайте трафик (1% → 5% → 50%). Старая система остаётся как fallback. Риск поломки бизнеса сводится к нулю, а команда приобретает уверенность.Смена правил
Успех первого модуля — не финал, а повод сменить правила. Зафиксируйте процесс (тесты, CI/CD, шаблоны). Введите правило: новый функционал — только в новых сервисах. Монолит перестаёт расти. Дальше вы не «боретесь с техдолгом» — вы выводите его из эксплуатации, начиная с самых опасных частей.
Заключение
Технический долг в региональном финтехе — это уже не проблема качества кода. Это системный кризис управления цифровыми активами.
Проведя полный анализ мы обнаружили ряд серьезных архитектурных проблем, где код проекта "застрял" во времени. Это может привести к серьезным проблемам особенно в финансовом секторе. В данном случае это нечто большее чем техдолг, а прямые нарушение базовых требований ФСТЭК к защите информации и указаний ЦБ РФ о киберустойчивости.
Время для стратегического решения наступило.
Андрей
Генеральный директор Digital агентства Фкор
