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

Ваш продукт работает правильно. Но это не значит, что он работает безопасно.

Введение: работает — ещё не значит безопасно

Команда выкатывает новый фичер: промокоды к запуску, реферальная программа, бонусная система. Продакт проверяет happy path — всё работает. QA прогоняет тест-кейсы — зелёно. Релиз в продакшн.

Через две недели выясняется: кто-то слил скидку через Telegram-канал, и несколько тысяч аккаунтов забрали весь промо-бюджет за ночь. Или: некий пользователь написал скрипт, который делает возврат до того, как платёж фиксируется в системе, и покупает товар фактически бесплатно.

Ни один сканер этого не нашёл бы. WAF не заблокировал бы. Потому что с технической точки зрения запросы были абсолютно легитимны.

Это и есть уязвимости бизнес-логики. Они отличаются от классических CVE принципиально: приложение работает ровно так, как запрограммировано — просто логика оказалась неполной.

Эта статья — практическое руководство для CTO, Tech Lead и AppSec-специалистов о том, что нужно проверять в продукте до запуска, чтобы не обнаружить мошенничество по факту убытков.

Что такое уязвимости бизнес-логики и почему они особенные

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

Уязвимости бизнес-логики — это изъяны в проектировании и реализации правил, по которым приложение обрабатывает данные, управляет потоками операций и принимает решения [1]. Атакующий не взламывает приложение — он использует его функциональность так, как разработчик не предполагал.

Разница принципиальная: SQL-инъекцию или XSS можно обнаружить паттерн-матчингом. Уязвимость бизнес-логики возникает там, где приложение делает именно то, что написано в коде — но не то, что хотел продуктовый менеджер [4]. WAF не понимает контекст. Он не знает, что пользователь не должен применять один и тот же промокод трижды, потому что в запросе нет ничего «неправильного» — просто бизнес-правило не закодировано на сервере [5].

Статистика, которую стоит знать

Цифры за последние два года говорят сами за себя:

• Доля атак на бизнес-логику в API-трафике выросла с 17% в 2022 году до 27% в 2023-м — рост 59% за год, по данным Imperva [5].
• В отчёте HackerOne 2024/2025 уязвимости бизнес-логики вошли в топ-10 наиболее распространённых, с приростом 5% год к году [5].
• Средняя стоимость взлома в 2024 году достигла $4,88 млн — рост 10% к предыдущему году, крупнейший скачок с пандемии [28].
• 22% веб-приложений имеют логические уязвимости, по оценке Imperva [6].
• В крипто- и блокчейн-индустрии количество инцидентов с бизнес-логикой выросло на 37% в 2023 году [5].

В конце 2025 года российские эксперты по кибербезопасности назвали ошибки в бизнес-логике одной из ключевых угроз 2026 года: «Подобные ошибки не выявляются стандартными средствами, но их можно использовать во вред» [24].

Классификация: OWASP Business Logic Abuse Top 10

В мае 2025 года OWASP выпустил первый специализированный проект Business Logic Abuse Top 10 [3]. Это принципиально новая таксономия: уязвимости классифицируются не по технической реализации, а по тому, как они нарушают логику потоков состояний приложения. Выделены три группы проблем:

1. Tape Issues — некорректная работа с данными: их повреждение, подмена, несогласованность.
2. State Issues — неправильные переходы между состояниями приложения (например, пропуск обязательного шага в checkout).
3. Transition Issues — уязвимости в условиях перехода: race conditions, слабые валидации.

MITRE фиксирует эту проблему в двух записях: CWE-840 (Business Logic Errors) и CWE-841 (Improper Enforcement of Behavioral Workflow) [26]. OWASP WSTG посвящает бизнес-логике отдельный раздел с восемью категориями тестов [18].

Карта угроз: где мошенничество прячется в вашем продукте

Ниже — точки, которые атакующие проверяют в первую очередь. Это не теоретический список: каждый из паттернов встречался в реальных инцидентах.

1. Ценообразование и параметры заказа

Если цена передаётся клиентом — она будет изменена. Это базовое правило, которое нарушают многие команды под давлением скорости разработки. Атакующий берёт Burp Suite, перехватывает запрос на checkout и меняет значение price с 9999 на 1. Если сервер не перепроверяет цену по product_id в базе данных, а принимает то, что пришло от клиента, — заказ оформляется [15].

Аналогичная история с отрицательным количеством: если quantity=-1 не валидируется, система может начислить кредит вместо списания [4]. Другой вариант — манипуляция валютой: переключение между валютами с разным курсом в момент транзакции.

Правило: все security-relevant значения (цена, скидка, сумма, количество) должны вычисляться исключительно на сервере. Клиентский стейт — это input, а не истина [22].

2. Промокоды, купоны и скидки

73% ретейлеров по всему миру столкнулись с abuse промокодов или купонов [16]. Векторы:

• Многократное использование одного промокода одним пользователем или с разных аккаунтов.
• Применение нескольких скидок там, где допустима только одна (discount stacking) [1].
• Предсказуемые коды: если промокод выглядит как SUMMER10, SUMMER20, SUMMER30 — злоумышленник переберёт серию [16].
• Истёкшие промокоды, которые сервер принимает из-за некорректной проверки даты.
• Race condition: два параллельных запроса используют промокод до того, как первый зафиксировался в базе.

На пиковых событиях (Black Friday, запуск продукта) до трети пользователей купонов могут быть «фейковыми шопперами» без реального намерения покупки [16].

3. Возвраты и рефанды

Рефанд-мошенничество — отдельная экосистема. Профессиональные «рефандеры» рекламируют свои услуги на форумах и в мессенджерах [17]. Распространённые схемы:

• Возврат пустой коробки или замена на сломанный аналог.
• Ложное заявление о недоставке при наличии трекинга на другую посылку.
• Дублированный рефанд: один и тот же RMA-номер используется дважды из-за гонки состояний.
• Возврат и чарджбэк одновременно: пользователь получает деньги и от магазина, и от банка.
• Возврат цифрового продукта после использования — особенно актуально для SaaS и игрового контента.

Согласно отчёту Appriss Retail 2026, злоупотребления составляют 12% всех возвратов, что эквивалентно $86 млрд [13].

4. Реферальные программы и многоаккаунтность

Реферальные программы — идеальный вектор для создания фиктивных аккаунтов. Один человек регистрирует 50 аккаунтов, реферит сам себя и получает бонусы. Для защиты недостаточно одного email — нужна кластеризация по IP, device fingerprint, платёжным инструментам и поведенческим паттернам [11].

Multi-accounting актуален и в B2B-продуктах: бесплатный trial, ограниченный по числу пользователей или компаний, обходится созданием отдельных тенантов на каждое юридическое лицо. Злоумышленники используют disposable email-адреса, VoIP-номера и датацентровые IP — все эти сигналы должны проверяться при регистрации [11].

5. Многошаговые флоу и пропуск шагов

Checkout, верификация, онбординг, заявка на кредит — любой многошаговый процесс уязвим к пропуску шагов. Классический пример из OWASP WSTG: если аутентификация состоит из шагов 1→2→3, что происходит, если пользователь перейдёт напрямую с шага 1 на шаг 3? [18]

Приложения, которые хранят состояние флоу только на клиенте (в куках, параметрах URL, localStorage), особенно уязвимы. Атакующий манипулирует этими параметрами, чтобы пропустить верификацию, оплату или проверку возраста. Принцип защиты: состояние флоу должно быть эксплицитным и управляться сервером [20].

Российский кейс: в ходе пентеста была обнаружена система записи на услуги, где SMS-код при подтверждении записи проверялся клиентской стороной, а не сервером — что позволяло записывать любых пользователей без их ведома [25].

6. Race Conditions (состояния гонки)

Race conditions — наиболее технически сложный вид уязвимостей бизнес-логики. Возникают, когда два или более параллельных запроса обращаются к одному ресурсу до того, как первый успел зафиксировать изменение [7].

Реальный кейс: Starbucks в 2015 году потерял миллионы долларов из-за race condition в функции пополнения подарочных карт — атакующий мог пополнить карту несколько раз, используя один платёжный инструмент, делая параллельные запросы [6]. В 2024 году аналогичная уязвимость CVE-2024-58248 позволяла обналичить подарочную карту несколько раз с помощью single-packet атаки [7].

Вектора race conditions:

• Параллельное списание бонусных баллов.
• Двойная трата подарочных сертификатов.
• Параллельные запросы на вывод средств в финансовых приложениях.
• Одновременное применение одного промокода.

Защита: идемпотентные операции, advisory locks на уровне базы данных, атомарные транзакции. И обязательно — тесты, которые имитируют параллельные запросы [22].

7. Привилегии и авторизация на уровне логики

OWASP выделяет отдельный класс: privilege escalation через бизнес-логику. Это не IDOR в классическом понимании, а сценарии типа: «обычный пользователь может вызвать административный workflow, подобрав правильную последовательность API-вызовов» или «пользователь может утвердить свой же запрос, манипулируя цепочкой согласования» [27].

Другой распространённый паттерн: изменение параметра role в запросе. Если сервер не валидирует роль независимо от клиентского входа — передача role=admin даёт несанкционированный доступ [6].

8. API-специфические риски

API amplifies everything — хорошее и плохое. Бизнес-логические уязвимости в API особенно опасны, потому что:

• Нет UI-валидаций, которые хотя бы создают трение.
• Автоматизация атак тривиальна.
• Один endpoint может обслуживать множество клиентов с разными ролями.

Показательный кейс: в 2018 году API USPS раскрыл данные 60 миллионов пользователей — не из-за уязвимости, а из-за логической ошибки авторизации: любой авторизованный пользователь мог запросить данные любого другого [5]. Технически система работала правильно — бизнес-правило было просто не закодировано.

Что сканеры не найдут никогда: почему нужен ручной анализ

Автоматические инструменты — DAST, SAST, WAF — работают по паттернам. Они ищут известные сигнатуры: инъекции, некорректную сериализацию, слабые заголовки. Бизнес-логические уязвимости не имеют сигнатуры по определению [8].

WAF видит легитимный HTTP-запрос с корректными параметрами — и пропускает его [5]. DAST не знает, что промокод нельзя применять дважды, потому что это правило нигде не задокументировано в машиночитаемом формате. SAST не увидит отсутствующую server-side валидацию цены — он видит только то, что написано в коде, а не то, чего в коде нет.

OWASP WSTG прямо указывает: «Тестирование бизнес-логики — это ручное искусство, зависящее от навыков тестировщика и его знания бизнес-процесса» [18]. Это не значит, что инструменты бесполезны — они помогают наблюдать трафик и формировать запросы. Но решение о том, корректна ли логика, принимает человек.

Исследование 2025 года подтвердило: несмотря на прогресс AI в детектировании, человеческая экспертиза остаётся ключевой, потому что бизнес-логика контекстно-зависима, у каждого приложения уникальные workflow, и творческие abuse-сценарии возникают постоянно [5].

Практическое руководство: что проверять до запуска

Шаг 1. Threat modeling от бизнес-процесса, а не от технологии

Классический threat modeling начинается с технической архитектуры: data flows, trust boundaries, точки входа. Для бизнес-логики нужно добавить другой угол: что произойдёт, если пользователь будет действовать нечестно?

Для каждой функциональности спросите:

• Какие правила регулируют это действие? Где они закреплены — в коде на сервере или в UI?
• Что произойдёт, если шаги workflow будут выполнены в другом порядке? Или если шаг будет пропущен?
• Можно ли эту операцию выполнить дважды? Параллельно?
• Что случится с экстремальными значениями: quantity=-1, amount=0.001, date в прошлом?
• Кто получает выгоду от некорректного поведения системы?

OWASP рекомендует: рассматривать приложение как конечный автомат и явно определять допустимые переходы между состояниями [22].

Шаг 2. Чек-лист для основных зон риска

Ценообразование и платежи:

1. Все ценовые параметры вычисляются на сервере, не принимаются от клиента.
2. Проверяется соответствие суммы заказа сумме платежа перед подтверждением.
3. Отрицательные и нулевые количества/суммы валидируются.
4. Транзакции атомарны: деньги не списываются до подтверждения доступности товара.
5. Возврат оформляется только на оригинальный платёжный инструмент.

Промокоды и бонусы:

1. Промокоды привязаны к пользователю или аккаунту, а не только к сессии.
2. Реализован механизм idempotency: одновременные запросы на применение одного кода не приводят к двойному списанию.
3. Ограничения по числу применений проверяются с блокировкой на уровне БД.
4. Промокоды не предсказуемы: случайные строки, а не последовательные CODE01, CODE02.
5. Комбинирование скидок явно запрещено или явно разрешено — не по умолчанию [16].

Возвраты и рефанды:

1. Рефанд инициируется только на сумму, не превышающую оригинальный платёж.
2. RMA-токены — одноразовые: сгорают после первого использования [13].
3. Параллельные запросы на рефанд по одному заказу блокируются.
4. Аномальная активность (>X возвратов в неделю от одного аккаунта) логируется и флагируется.

Workflow и многошаговые процессы:

1. Состояние процесса хранится и валидируется на сервере.
2. Переход к следующему шагу возможен только после успешной валидации предыдущего.
3. Прямые вызовы URL/API для «перепрыгивания» шагов возвращают ошибку, а не продолжают процесс.
4. Повторное выполнение шага (replay) не приводит к двойному начислению бонусов или двойному выполнению действия [20].

Race conditions:

1. Критические операции (списание, начисление, применение купона) защищены advisory locks или атомарными транзакциями.
2. В тестах есть concurrent-тесты: два параллельных запроса не должны оба завершиться успехом там, где возможен только один.
3. Используется idempotency key для API-вызовов, меняющих состояние.

Авторизация и роли:

1. Роль пользователя проверяется на сервере для каждого действия, не полагаясь на клиентский параметр.
2. Пользователь не может утвердить собственный запрос в approval-цепочках.
3. Последовательность вызовов API не позволяет добраться до privileged-функциональности, минуя проверки.

Шаг 3. Разработка abuse cases

OWASP WSTG настаивает: тестирование бизнес-логики требует разработки misuse cases — негативных сценариев, дополняющих функциональные тесты [18]. Практический подход:

Для каждого бизнес-правила задайте вопрос: «Что произойдёт, если пользователь попробует нарушить это правило?» — и проверьте. Например:

• Правило «промокод действует один раз» → Попробовать применить его в двух параллельных запросах.
• Правило «возврат только в течение 30 дней» → Попробовать с датой за пределами окна.
• Правило «нельзя одобрить собственный запрос» → Попробовать манипуляцией с параметром approver_id.

OWASP Business Logic Security Cheat Sheet рекомендует: для каждого инварианта, выявленного при threat modeling, написать тест, который явно его нарушает и проверяет, что система отвергает такой запрос [22].

Шаг 4. Logging и мониторинг — необходимый минимум

Даже идеально спроектированная логика будет столкнётся с creative abuse. Logging — это то, что позволяет заметить и отреагировать [22]. Минимально необходимый набор сигналов для мониторинга:

• Множественные регистрации с одного IP/device fingerprint.
• Аномально высокая частота применения промокодов.
• Возвраты без соответствующих заказов или с превышением суммы.
• Попытки обращения к privileged-эндпоинтам от unprivileged-пользователей.
• Нестандартные последовательности вызовов API (шаг 3 без шага 2).
• Параллельные запросы с одинаковыми параметрами от одного аккаунта.

Логи по операциям с деньгами, правами и значимыми действиями должны быть tamper-evident и отдельными от общих application logs [22].

Шаг 5. Code review как точка контроля

Многие бизнес-логические уязвимости закладываются в момент написания кода — под давлением сроков, когда «сначала сделаем работающее, потом защитим». Проблема: «потом» не наступает.

Именно здесь ревью изменений до merge особенно важно. Проверяйте не только то, что написано, но и то, чего нет: нет ли серверной валидации цены? нет ли idempotency key? нет ли блокировки для concurrent-операций? Новая зависимость или изменение в конфиге платёжной системы — это потенциальный вектор, который нужно смотреть с пристальным вниманием до того, как он попадёт в продакшн.

Типичные ошибки команд

«Мы проверили на happy path — всё работает»

Functional testing верифицирует корректное поведение. Abuse testing верифицирует некорректное. Это разные задачи с разными мышлением и инструментами [18]. Прохождение всех функциональных тестов не говорит ничего о том, устойчива ли логика к злоупотреблениям.

«WAF нас защитит»

WAF не понимает бизнес-контекст. Запрос на применение промокода дважды технически корректен — у него правильный синтаксис, правильные заголовки, правильная аутентификация. WAF пропустит его [5].

«Клиент всё равно не будет менять запросы»

Это неверное предположение. Любое поле в HTTP-запросе — включая скрытые поля форм, параметры, выставленные JavaScript, и значения из предыдущих ответов — является входными данными от потенциального атакующего [22]. Инструменты типа Burp Suite доступны каждому.

«Мы исправим после запуска»

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

«Это маловероятный сценарий»

Профессиональные мошеннические группы работают как SaaS-бизнесы: у них подписки, поддержка, автоматизация [9]. Как только продукт становится заметным, сканирование на типовые уязвимости начинается автоматически.

Инструменты и методология

Ручное тестирование

Ключевые инструменты для исследования бизнес-логики:

• Burp Suite — перехват и модификация HTTP-запросов, тестирование параметров.
• OWASP ZAP — анализ workflow в web-приложениях.
• Postman / Insomnia — прямые вызовы API в нестандартном порядке.

Automated abuse testing

Автоматизировать конкретные abuse-сценарии можно и нужно после их идентификации:

• Concurrent-тесты на race conditions: большинство фреймворков позволяют отправлять параллельные запросы и проверять итоговое состояние.
• Property-based testing для граничных значений.
• Contract testing для проверки серверной валидации параметров.

Документирование правил как код

OWASP WSTG рекомендует: каждый бизнес-инвариант должен быть задокументирован и покрыт тестом [22]. Это одновременно документация и защита от регрессий. Если правило «промокод применяется один раз» есть в тесте — его невозможно незаметно сломать при рефакторинге.

Бизнес-логика в AI-эпоху: новые риски

Генеративный AI ускорил разработку. Но AI не всегда понимает бизнес-контекст. Код, написанный с помощью AI-ассистента, технически может быть корректным и даже проходить тесты — но при этом не реализовывать нужное бизнес-правило.

Типичные примеры из практики AI-кодинга:

• Промокод валидируется на клиенте вместо сервера — AI сгенерировал «работающий» код, но не там, где нужно.
• Отсутствие idempotency key в API-вызове — функционально всё работает, пока нет параллельных запросов.
• Мягкая валидация вместо жёсткой: if amount > 0 вместо if 0 < amount <= max_allowed.

Рабочий pull request — не то же самое, что безопасный pull request. AI-ассистент помогает написать код быстрее, но responsibility за то, что бизнес-правила закодированы корректно и полностью, остаётся за командой.

Ревью изменений до merge — особенно изменений в логике транзакций, ценообразования, авторизации и конфигах платёжных шлюзов — это последний рубеж, где ошибку можно поймать до того, как она попадёт в продакшн. Именно в этой точке HighVibe работает как дополнительный слой контроля: анализирует конкретное изменение в коде и конфигах, объясняет потенциальный риск простым языком и предлагает следующий шаг — до merge и релиза highvibe.dev.

Decision framework: когда достаточно предупреждения, а когда нужен жёсткий gate

Не все бизнес-логические риски одинаковы. Вот упрощённый фреймворк для расстановки приоритетов:

Жёсткий gate (блокировать до исправления):

• Цена или сумма транзакции принимается от клиента без серверной валидации.
• Отсутствует защита от race condition в финансовых операциях.
• Шаги верификации платежа или идентификации можно пропустить.
• Privileged-действие доступно без проверки роли на сервере.

Предупреждение (флаг для ревью, не блокировать релиз):

• Отсутствуют rate limits на применение купонов.
• Нет логирования аномальной активности по возвратам.
• Реферальная программа не фильтрует disposable emails.

Принять и мониторить:

• Граничные кейсы в бизнес-правилах, где риск минимален.
• Функции, доступные только внутренним пользователям.

Заключение: до запуска или после

Бизнес-логические уязвимости находят не сканерами — их находят мошенники, которые терпеливо ищут, как именно ваш продукт работает. И они найдут раньше, чем вы.

Правильный момент для проверки — не после первого инцидента, а на этапе проектирования и в момент code review. Конкретно: когда feature ещё в PR, когда конфиг платёжной системы ещё не в продакшне, когда логика промокодов ещё не закоммичена в main.

Основной принцип: сервер не доверяет клиенту ни в чём. Все правила — серверные. Все состояния — серверные. Все переходы — валидируются на сервере. Остальное — технические детали реализации.

Это звучит как банальность — и именно поэтому нарушается так часто.

Источники

[1] OWASP Foundation — "Business Logic Vulnerability" — https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability

[2] Medium / a0xtrojan — "Bug Bounty Hunter's Checklist for Business Logic Flaws" — https://medium.com/@a0xtrojan/bug-bounty-hunters-checklist-for-business-logic-flaws-325fee8ff73c

[3] OWASP Foundation — "OWASP Top 10 for Business Logic Abuse" — https://owasp.org/www-project-top-10-for-business-logic-abuse/

[4] PortSwigger Web Security Academy — "Business Logic Vulnerabilities" — https://portswigger.net/web-security/logic-flaws

[5] Medium / InstaTunnel — "Business Logic Flaws: The Vulnerabilities No Scanner Can Find" — https://medium.com/@instatunnel/business-logic-flaws-the-vulnerabilities-no-scanner-can-find-b52d64692f4d

[6] Securityium — "What Are Business Logic Vulnerabilities?" — https://www.securityium.com/what-are-business-logic-vulnerabilities/

[7] Outpost24 — "Business Logic Attacks: The Silent Future of Cyberattacks" — https://outpost24.com/blog/future-business-logic-attacks/

[8] Cequence Security — "What is Business Logic Abuse?" — https://www.cequence.ai/blog/bot-management/business-logic-abuse/

[9] AU10TIX — "Top Fraud Trends for 2025–2026" — https://www.au10tix.com/blog/top-fraud-trends-for-2024-2025/

[10] Sumsub — "Fraud Detection and Prevention: Best Practices for 2025" — https://sumsub.com/blog/fraud-detection-and-prevention-best-practices/

[11] iDenfy — "Best 9 Fraud Prevention Solutions in 2026" — https://idenfy.com/blog/best-fraud-prevention-solutions/

[12] Accertify — "First-Party Ecommerce Fraud Prevention" — https://www.accertify.com/resource/first-party-ecommerce-fraud-prevention-8-tips-to-keep-your-business-safe-from-returns-abuse/

[13] Cahoot — "Ecommerce Return Fraud vs. Refund Fraud" — https://www.cahoot.ai/strategies-for-preventing-ecommerce-return-and-refund-fraud/

[14] Sumsub — "E-Commerce Fraud Prevention: A Complete Guide for Online Merchants 2026" — https://sumsub.com/blog/ecommerce-fraud-prevention/

[15] GetAstra — "Security Testing for E-Commerce Websites" — https://www.getastra.com/blog/security-audit/security-testing-for-e-commerce-websites/

[16] Bluepear — "Coupon Fraud & Abuse Prevention" — https://bluepear.net/blog/coupon-abuse

[17] Signifyd — "Return Fraud: The Retailers' Complete Guide" — https://www.signifyd.com/blog/how-to-prevent-return-fraud/

[18] OWASP WSTG — "Introduction to Business Logic Testing" — https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/00-Introduction_to_Business_Logic

[19] Aptive — "OWASP WSTG Business Logic Testing Checklist" — https://www.aptive.co.uk/blog/owasp-wstg/business-logic-testing-checklist/

[20] OWASP WSTG — "Testing for the Circumvention of Work Flows" — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/06-Testing_for_the_Circumvention_of_Work_Flows

[21] Apiiro — "What Are Business Logic Vulnerabilities?" — https://apiiro.com/glossary/business-logic-vulnerabilities/

[22] OWASP Cheat Sheet Series — "Business Logic Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html

[23] OWASP WSTG — "Test Business Logic Data Validation" — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/01-Test_Business_Logic_Data_Validation

[24] Finance.mail.ru / РИА Новости — "Главные киберугрозы в 2026 году" — https://ria.ru/20251230/ekspert-2065540794.html

[25] RT Solar (Ростелеком-Солар) — "Уязвимости информационных систем российских компаний 2024" — https://rt-solar.ru/analytics/reports/5375/

[26] OWASP — "Business Logic Vulnerability: CWE references" — https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability

[27] GitHub OWASP — "New CS proposal: Business Logic Security" — https://github.com/OWASP/CheatSheetSeries/issues/2064

[28] IBM Newsroom — "IBM Report: Escalating Data Breach Disruption Pushes Costs to New Highs" — https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs