Предисловие

Прочность банковской системы определяется не одними отчётами для проверяющих. Её основа — это код и «железо». Если они не менялись пятнадцать лет, даже самые строгие правила становятся пустой бумажкой.

Мы провели внешний технический анализ публичных интерфейсов (фронтенд, 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 гг.). Такой код физически не может адаптироваться под разные размеры экранов без полной переписи.

Эта проблема создает определенные бизнес риски для всех организаций, не только финансовых:

  1. Потеря клиентов: Более 60% трафика сейчас идёт со смартфонов. Нечитаемый интерфейс = отказ от услуги.

  2. Блокировка развития: Невозможно запустить современное мобильное приложение или PWA (Progressive Web App), так как нет адаптивного API и компонентов.

  3. Репутационный ущерб: Для пользователя «ломающийся» сайт — признак ненадёжности и неуважения.

Однако, даже если с мобильной вёрсткой всё в порядке, это не гарантирует безопасность. Следующий слой проблем — устаревшие JavaScript-библиотеки и зависимости, которые мы обнаружили в коде большинства проверенных систем. Именно они зачастую становятся точкой входа для реальных атак.

Устаревшие библиотеки, потенциальные уязвимости

Эта проблема одна из самых распространенных в региональных банках Российской Федерации. 9 из 10 банков проверенных нами имели очень старый набор технологий, который может иметь кучу уязвимостей. Ниже привели ряд самые яркие примеры техдолга

----------------

Банк X

Банк Y

Банк Z

Front-end

jQuery 1.8.3 (2012). Содержит XSS-уязвимость CVE-2015-9251.

XSS-уязвимость

jQuery 2.1.0 + UI 1.10.3 (оба 2013). Конфликтующий стек с уязвимостями (CVE-2015-9251, CVE-2016-7103).

Уязвимости

HTML 4.0 (1999), .htm, windows-1251.Архитектура, физически блокирующая любые современные интеграции.

Back-end

PHP 5.1.2 (2005). Катастрофа. 15+ лет без патчей. Открыт для RCE и SQL-инъекций.

Уязвимости

Java 7, вышла в 2011 году

spring framework: 3.1, вышел в 2011 году

Отсутствует

Сервер

Nginx (как прокси)

Nginx (как балансировщик)

Nginx (как прокси)

? Риск

Банк максимально уязвим к большинству атакам, в результате чего могут пострадть клиенты

Иллюзия контроля при растущих затратах и скрытых уязвимостях.

Бизнес заперт в прошлом. Развитие невозможно без полной перезагрузки.

Представленные кейсы — не исключения, а системное явление. Накопление техдолга в региональном финтехе достигло точки, где безопасность и бизнес-развитие становятся взаимоисключающими понятиями. В большинстве проектов имеются костыли, создается иллюзия, что всё работает и всё хорошо, но это не так.

Публичный localhost

Анализ DNS-записей выявил не просто разрозненную архитектуру, а критические ошибки конфигурации, которые не должны существовать в принципе. Самым вопиющим примером стал публичный субдомен localhost.

  1. localhostэто зарезервированное сетевое имя для обращения компьютера к самому себе. Его вынос в публичное DNS — грубейшее нарушение базовых принципов сетевой безопасности и администрирования.

  2. Прямое указание на низкую квалификацию или полное отсутствие контроля. Такая ошибка не появляется случайно в продакшене. Она говорит о том, что процессы code review, тестирования и выкладки изменений в инфраструктуру либо отсутствуют, либо полностью провалены.

Существует ли выход из этой проблемы?

Когда техдолг становится системным, классические подходы — «нанять больше разработчиков» или «выделить год на переписывание» — не работают. Первые утонут в поддержке легаси, второй проект почти наверняка провалится из-за неподъёмного объёма и рисков. Отраслевая практика показывает, что единственный устойчивый путь — стратегия управляемой эрозии legacy. Её можно свести к трём принципам.

  1. Что болит больше всего?
    Откажитесь от глобального аудита. За 1-2 недели найдите один модуль, где сходятся: операционная боль (чаще всего ломается), критический риск (работает на PHP 5.1/jQuery 1.x) и возможность изоляции. Всё остальное — шум. Первый шаг — всегда один.

  2. Не меняем всё и сразу!
    Не переписывайте. Замещайте. Постройте новый микросервис рядом со старым кодом. Через feature flag или роутер плавно переключайте трафик (1% → 5% → 50%). Старая система остаётся как fallback. Риск поломки бизнеса сводится к нулю, а команда приобретает уверенность.

  3. Смена правил
    Успех первого модуля — не финал, а повод сменить правила. Зафиксируйте процесс (тесты, CI/CD, шаблоны). Введите правило: новый функционал — только в новых сервисах. Монолит перестаёт расти. Дальше вы не «боретесь с техдолгом» — вы  выводите его из эксплуатации, начиная с самых опасных частей.

Заключение

Технический долг в региональном финтехе — это уже не проблема качества кода. Это системный кризис управления цифровыми активами.

Проведя полный анализ мы обнаружили ряд серьезных архитектурных проблем, где код проекта "застрял" во времени. Это может привести к серьезным проблемам особенно в финансовом секторе. В данном случае это нечто большее чем техдолг, а прямые нарушение базовых требований ФСТЭК к защите информации и указаний ЦБ РФ о киберустойчивости.

Время для стратегического решения наступило.

Андрей

Генеральный директор Digital агентства Фкор

Комментарии (32)


  1. PereslavlFoto
    03.01.2026 01:16

    Время для стратегического решения наступило.

    Извините меня за резкость, но из-за вашего «стратегического решения» я не могу запустить на Android 5.1 никакого банковского приложения. Исправляя ваш любимый технический долг, программисты привели к тому, что закрыли мне доступ к моим счетам.

    Скажу вам начистоту, прямо от сердца: прежние «стратегические решения» отлично работали безо всяких исправлений. А после исправлений — они перестали работать.


    1. Fcore Автор
      03.01.2026 01:16

      Да, но в данной статье мы рассматривали только веб-сайты. К сожалению даже крупные технологические гиганты, по типу Сбера не дают возможность установить своё приложение на версию Android ниже 6. Это обусловенно, погоней за новыми функциями, которые на телефоне ниже это версии могут работать некорректно.

      Как правило в таком случае можно пользоваться веб версией. Она должна быть идеально защищена и не иметь таких "долгов" как в примерах указанных выше.

      Мы сами разрабатываем приложения, и тестируем их на Android от версии 7.0, поддержка приложений для старых версий может стоить определенных средств, а учитывая что доля пользователей Android <7.0 минимальная, компании просто отказываются от этого


      1. PereslavlFoto
        03.01.2026 01:16

        Это обусловено новыми функциями

        Можно дать один пример такой новой функции, без которой моя жизнь превратится в ад? Раньше, без этих функций, всё было очень даже хорошо.

        Вы правы, остаётся веб-версия, однако некоторые банки уже догадались отключить её.


        1. Fcore Автор
          03.01.2026 01:16

          Процитирую с сайта, нашел вот

          Сбер прекратил поддержку Android ниже 8 версии, потому что старые операционные системы не обеспечивают должный уровень безопасности, не поддерживают современные технологии шифрования и новые функции приложения.

          К сожалению я не разработчик в Сбере и не могу сказать точную причину :(


          1. PereslavlFoto
            03.01.2026 01:16

            Причём браузер в такой операционной системе всё поддерживает, всё обеспечивает. Умилительный Сбербанк готов принимать деньги, однако не готов давать клиентам доступ к их деньгам. Надо же, какие лапочки.


            1. Fcore Автор
              03.01.2026 01:16

              Браузер работает иначе, чем мобильное приложение. И даже если у человека Android 3.0, Сбер в нём должен хорошо работать.


              1. d3d11
                03.01.2026 01:16

                Ну вот из за ваших советов переходить на модно-молодежные веб-технологии, и в браузере не будет работать хорошо.


    1. pol_pot
      03.01.2026 01:16

      5.1 уже давно вымерли. Претензии надо предъявлять гуглу и андроиду, почему они не позволяют обновлять старые устройства, или к производителям чипов, это вроде они не дают делать новые ядра для своих чипов.


      1. PereslavlFoto
        03.01.2026 01:16

        Если они вымерли, где я могу получить другой смартфон взамен этого?


        1. sotland
          03.01.2026 01:16

          В СССР, там не то что смартфоны, там квартиры в замен давали


  1. MegaHard
    03.01.2026 01:16

    Современный веб - это динамичные веб-приложения, адаптивные интерфейсы и интерактивные элементы.

    А ещё куча тормозов при загрузке, скачущий туда-сюда текст при попытке промотать, маленький кусочек окна, оставшийся для основного контента, не работающий Ctrl+V (да как вы этого добились!) и т.д.


    1. PereslavlFoto
      03.01.2026 01:16

      Да, да, массаракш!!!


    1. Fcore Автор
      03.01.2026 01:16

      Главное нанимать правильных разработчиков и всё будет хорошо), а то наберут людей которые не знают как компьютером пользоваться


      1. ermouth
        03.01.2026 01:16

        Главное нанимать правильных разработчиков

        Намекните им плиз, что не нужен png на 2 мега там, где достаточно progressive jpeg на 100 кило )


      1. nerudo
        03.01.2026 01:16

        О, значит и хабр программируют неправильные программисты. Раньше я сразу мог попасть куда надо, а ныне жамкаю на свою рожу справа наверху и меню начинает динамически загружаться. Время загрузки от полусекунды до бесконечности.


      1. Mr_Cheater
        03.01.2026 01:16

        У Вас опечатка в предложении «компьютеры и телефоны должны быть только у людей, которые умеют ими пользоваться как минимум на уровне гика»


  1. DjUmnik
    03.01.2026 01:16

    Навигация через перезагрузку страницы устарела? Она ведь применяется на миллионах сайтов до сих пор.

    ЗЫ.какой дурак решил писать банковское приложение на php?

    Тут дело даже не в самом языке, а в том, что типичных пхп-шников нельзя и близко подпускать к чему-то серьезному.


    1. Dhwtj
      03.01.2026 01:16

      Всё нормально. Глубже взломщиков встретит надёжный COBOL)


    1. Fcore Автор
      03.01.2026 01:16

      Мы проверили только 10 банков, у восьми из них php очень старой версии как минимум)


  1. d3d11
    03.01.2026 01:16

    Потеря клиентов: Более 60% трафика сейчас идёт со смартфонов. Нечитаемый интерфейс = отказ от услуги.

    Для понимания: эти фреймсеты, найденные автором, используются в desktop only интерфейсе клиент-банка. (я даже подозреваю какого банка). Десктоп интерфейс для бухгалтеров - какие смартфоны и мобильные клиенты?

    Старый конь борозды не испортит. Уязвимости, конечно, надо закрывать, но гнаться за последними писками моды - это наверно не для банковской сферы.


    1. RichardMerlock
      03.01.2026 01:16

      Автор нарыл ложный техдолг значит.


    1. nerudo
      03.01.2026 01:16

      Тут на хабре разработчиками рекламировался новый интернет-банк одного крупного регионального банка. Переписали под PWA, от одного вида тошнит и ничего на экран не влезает. Что примечательно - для юриков оставили старый вариант. Видимо понимая, что бухи их с любыми отходами сожрут, если им подпихнуть новый стильный современный дизайн.


    1. Fcore Автор
      03.01.2026 01:16

      Немного неправильно поняли, я общался с лпром одного из банков насчёт сайта в ответ получил: "У нас же работает, клиенты не жалуются"


  1. Dhwtj
    03.01.2026 01:16

    Это технологии, которые перестали быть актуальными 15 лет назад. И если так выглядит «лицо» системы, можно лишь догадываться, что происходит «под капотом

    Фронт у нас во многом такая же фигня: работает и ладно. Но бэк мы всё же обновляем для исправления логических ошибок и уязвимостей, стек обновляется паровозиком при необходимости.


    1. Fcore Автор
      03.01.2026 01:16

      Ну когда используется php 5.1.2 для личного кабинета банка, это немного неправильно будто


      1. Dhwtj
        03.01.2026 01:16

        Пыха обновлена ибо уязвимости. А вот древний jQuery мог и остаться в каком-то чулане


  1. Cib0rg
    03.01.2026 01:16

    >frameset на фронте

    >отсутствие адаптивной верстки

    >стек, который стабильно работает 20+ лет

    >АААААА, КОТОСТРОФА!

    С первых строк не покидало ощущение "Что я, блин, читаю?" То есть кол, который стабильно работает 15 и больше лет - это проблема, а решение - современные пикосервисы, которые рестартятся раз в час или приложения на электроне, которые жрут 2 гига рамы, чтобы показать пару цифр? Автор, если эит кликбейт - то он удался. Если статья на полном серьёзе - то тут, кажется, все очень плохо с логикой и инженерным подходом...


    1. Mr_Cheater
      03.01.2026 01:16

      Потеря клиентов: Более 60% трафика сейчас идёт со смартфонов. Нечитаемый интерфейс = отказ от услуги.

      Если отойти от технической точки зрения - когда вообще крупный бизнес интересовало мнение его пользователей? У них другие подходы к привлечению клиентов (не у всех, но если говорить о банках, то клиентам куда важнее процентная ставка, условия договора и т.д., и т.п.), и веб-морду большая часть клиентов видит уже после того, как начали пользоваться услугами банка. А то и вовсе только если приложение перестало работать.

      И так много где в крупном бизнесе. Не везде, разумеется, но я редко когда вижу адекватные сайты у подобных компаний. И дело не всегда упирается в техническую часть. Просто «а зачем?», увы.


    1. Fcore Автор
      03.01.2026 01:16

      Спасибо за комментарий,

      1. Про «стабильно работает».
      PHP 5.1.2 не «работает» - он существует. Его поддержка прекращена в 2009-2010 году. Это означает, что все уязвимости, найденные с 2010 по 2026 годы (включая критические RCE), в нём не исправлены. Система «стабильно уязвима» для любого автоматического сканера. Это не вопрос «старого кода», а вопрос гарантированной дыры в безопасности, которую нельзя закрыть легально.

      2. Про «решение - пикосервисы».
      Я согласен, слепой фанатизм к микросервисам - это болезнь. Но я не предлагаю «всё порубить в микросервисы». Я предлагаю   метод, при котором вы не трогаете старый работающий код. Вы строите новый модуль рядом и постепенно переключаете на него нагрузку, оставляя старый как fallback. Это снижает риск, а не увеличивает его. Именно для того, чтобы не было «рестартов раз в час».

      3. Про «логику и инженерный подход».
      Инженерный подход - это управление рисками, а не поклонение стабильности до последнего. Когда регулятор (ЦБ РФ, ФСТЭК) требует соответствия стандартам киберустойчивости, а ваш стек (PHP 5.1jQuery 1.x) физически не может им соответствовать, - это уже не инженерная, а бизнес-проблема. Штрафы, приостановка лицензии, утечка данных клиентов — вот цена «стабильности».


      1. d3d11
        03.01.2026 01:16

        А в PHP были RCE уязвимости? Я просто не в курсе. Ну, чтоб как в Next.js или Java2Shell?


        1. Fcore Автор
          03.01.2026 01:16

          Да были, их много

          https://cxsecurity.com/issue/WLB-2006040011 - например вот. Ещё можно на сайте https://nvd.nist.gov/ вбить php 5.1.2. и там посмотреть


      1. Cib0rg
        03.01.2026 01:16

        Я как-то даже не сразу понял, что именно меня так триггернуло.

        Во-первых, в статье смешаны реальные проблемы (типа мертвого РНР) и хрень в виде "не можем сделать ультраприложение". То есть дана не вся правда, а ровно столько её, чтобы бОльшая часть читателей решила, что остальные высказывания тоже правда. А это ну вот совсем не так.

        Да и по поводу пыхи тут ситуация двоякая. Конечно, для прицельной атаки это прямо подарок... Но в далёком 2017 году был у меня клиент, который идейно сидел на 98 винде по соображениям "да под неё малварь-то уже и вымерла". И, как ни странно, ни одного червя там я не видел, хотя пытался найти регулярно. Так что это в какой-то извращённой мере может быть безопасно.

        По поводу МС рядом - гладко было на бумаге. Начиная от квалификации того, кто модуль пишет, заканчивая квалификацией того, кто составляет требования, основываясь на артефактах седой древности, которых может и не быть. То есть это, опять же, замена стабильно работающего модуля ради неизвестно чего. Может, там вообще всё в докере крутится и безопасностью обмазано так, что внутри хоть гопак пляши - выхлоп нулевой будет (да, вряд ли, но оставим такой шанс). Смысл тогда это переводить на что-то другое? Одни операционные расходы.

        Ну и это банки, как-никак. Если у них требование регулятора исполняется другими методами - то, опять же, с точки зрения пользователя черного ящика, мне по барабану, из латуни внутри шестерёнки или из модного титано-вольфрамового сплава.