Материал

Уведомления по почте, SMS и push: ссылки, токены и ошибки бизнес-логики

Опубликовано: 18 июня 2026 Время чтения: 21 мин

Почему привычный канал доставки кода или ссылки давно стал целью — и что с этим делать команде до merge и релиза

Три канала, одна точка отказа

Когда команда проектирует функцию «восстановление пароля» или «подтверждение email», она, как правило, думает о пользовательском опыте: дойдёт ли письмо, не попадёт ли в спам, успеет ли пользователь ввести код. О безопасности думают реже — и ещё реже думают о безопасности всего потока целиком, а не отдельной кнопки.

Результат предсказуем. По данным Imperva State of API Security 2024, 27% всех API-атак в 2023 году составляли атаки на бизнес-логику — рост на 59% год к году [1]. HackerOne в своём отчёте за 2024–2025 годы фиксирует бизнес-логику в топ-10 наиболее частых уязвимостей с ростом на 5% [2]. Атаки этого класса работают именно там, где приложение функционирует корректно с технической точки зрения, но не так, как задумывал архитектор.

Уведомления — email, SMS и push — это ровно тот слой, где техническая корректность и логическая безопасность расходятся чаще всего.

Материал рассчитан на CTO, Tech Lead и AppSec-специалистов, которые хотят понять, где в этом слое возникает риск и что конкретно проверять до merge и релиза.

Часть I. Email-уведомления: ссылки, токены и то, куда они утекают

Что такое токен в контексте email-уведомления

Email с «magic link» для входа, письмо со ссылкой для сброса пароля или подтверждения адреса — во всех этих случаях в URL передаётся токен: уникальная строка, подтверждающая право пользователя выполнить действие. С точки зрения безопасности это секрет — такой же, как пароль. Разница в том, что токен передаётся по каналу (email), который разработчик не контролирует полностью.

OWASP Forgot Password Cheat Sheet формулирует требования к токену прямо [3]:

генерируется с помощью криптографически стойкого PRNG;
минимум 128 бит энтропии (22+ символа в base64/URL-safe кодировке);
привязан к конкретному пользователю в базе данных;
однократного использования и инвалидируется сразу после применения;
имеет срок жизни: для токена в ссылке — как правило, 15–60 минут [4].

На практике команды регулярно нарушают хотя бы один из этих пунктов. Академический анализ сброса паролей на крупных сайтах (DIMVA 2021) показал: часть токенов не истекает за 24 часа, часть используется многократно, часть содержит предсказуемые паттерны [5].

Куда утекает токен из URL

Самая недооценённая проблема — утечка токена через HTTP Referer-заголовок. Механизм простой: пользователь переходит по ссылке с токеном, страница подгружает сторонние ресурсы (аналитику, пиксели трекинга, CDN-скрипты), браузер отправляет полный URL в заголовке Referer этим третьим сторонам. Лог третьей стороны содержит токен. Если у злоумышленника есть доступ к этому логу — он может использовать токен до того, как это сделает пользователь [6].

Это не теоретическая атака. HackerOne-отчёт по Coursera (2018) описывает именно такую утечку: токен сброса пароля уходил на несколько внешних доменов через Referer [7]. Похожий баг в 2025 году попал в Hall of Fame USAGM [8].

Защита — заголовок Referrer-Policy: no-referrer или strict-origin-when-cross-origin на странице, куда ведёт ссылка. Дополнительно: не включать токен в query string, если можно передать его через POST или fragment.

Второй вектор — открытый редирект. Если приложение использует параметр вида ?redirect=https://example.com, злоумышленник может сконструировать ссылку ?redirect=https://attacker.com. Пользователь кликает, проходит аутентификацию, токен оседает в Referer-заголовке на сервере атакующего [9]. OWASP Testing Guide фиксирует этот паттерн как отдельный сценарий атаки: Token via Host Header Injection [3].

Третий вектор — логи приложения. Токены в URL регулярно попадают в access.log nginx/Apache, в логи reverse proxy, в трассировки APM. Хорошая практика: не логировать query string для чувствительных endpoints или маскировать параметр token в конфигурации логирования.

Magic links и NIST SP 800-63B-4

С августа 2025 года действует обновлённая версия NIST SP 800-63B-4 [10]. Она не запрещает magic links, но явно классифицирует email как «restricted authenticator channel» — канал с ограниченными гарантиями: нет подтверждения владения устройством, нет гарантии аутентичности отправителя без DKIM/DMARC, ограниченная энтропия.

Практический вывод, который делают из этого требования: magic link соответствует AAL1 при корректной реализации (хороший токен, короткий TTL, однократное использование). Для AAL2 нужен второй фактор.

Отдельный риск — компрометация почтового ящика через OAuth-грант. Атакующий через фишинг получает постоянный read-доступ к почте пользователя, не зная пароля и не ломая 2FA. Все последующие magic links читает он. Защита на уровне приложения — риск-основанная аутентификация: аномалия при входе с нового устройства запрашивает шаг-ап фактор.

Race condition в однократных токенах

Отдельный класс ошибок — race condition при проверке «использован ли токен». Типичная реализация:

SELECT used_at FROM tokens WHERE token = ?
IF used_at IS NULL THEN
  UPDATE tokens SET used_at = NOW() WHERE token = ?
  -- действие

При двух одновременных запросах в окне между SELECT и UPDATE оба потока видят used_at = NULL и оба выполняют действие. В расследовании 2024 года описан реальный инцидент: два клика с разницей 200 миллисекунд позволили злоумышленнику, перехватившему ссылку из скомпрометированного ящика, использовать её одновременно с легитимным пользователем [11].

Правильная реализация — атомарная операция: UPDATE tokens SET used_at = NOW() WHERE token = ? AND used_at IS NULL RETURNING *. Действие выполняется только если UPDATE затронул ровно одну строку.

Ошибки такого рода особенно часто появляются в AI-генерируемом коде: LLM-ассистент реализует «рабочую» логику сброса пароля, не закладывая атомарность — потому что в примерах из документации её тоже нет. PR выглядит корректно, тесты проходят, а race condition проявляется только под нагрузкой или при целенаправленной атаке. Именно такие изменения — новый auth-endpoint с нетривиальной логикой токена — полезно разбирать до merge, а не после инцидента.

Часть II. SMS-уведомления: модель угроз деградировала быстрее, чем успела устареть

Почему SMS стал слабым звеном

SMS-OTP появился как шаг вперёд от паролей. Проблема в том, что SS7 — телекоммуникационный протокол 1970-х, по которому SMS маршрутизируется между операторами, — никогда не проектировался с расчётом на противника внутри сети. Аутентификации между операторами нет, поэтому атакующий с доступом к SS7-узлу может перехватить сообщение или перенаправить его на другой номер [12].

Атаки задокументированы в production: Salt Typhoon (2024), SK Telecom (2025), Liminal Panda. FBI и CISA выпустили совместное предупреждение в декабре 2024 года по итогам Salt Typhoon, прямо рекомендовав отказаться от SMS-аутентификации [13].

SIM-swap — социальная инженерия против оператора. Атакующий убеждает службу поддержки перенести номер на свою SIM-карту. После этого все SMS, включая OTP, приходят ему. Инструмент хорошо известен: использовался против криптовалютных кошельков, знаменитостей, политиков.

NIST SP 800-63B-4 (2024) убрал SMS из перечня методов, удовлетворяющих AAL2, именно из-за комбинации SS7-уязвимостей, SIM-swap и фишинга OTP в реальном времени [10]. FINRA прекратила принимать SMS как допустимый метод MFA в июле 2025 года. ОАЭ потребовали полного отказа от SMS/email OTP в финансовых сервисах к марту 2026 года [13].

Отдельная уязвимость: Android и чтение SMS без разрешений

CVE-2025-10184 — уязвимость в Android, позволяющая любому установленному приложению читать SMS-данные из системного провайдера без явного разрешения и без уведомления пользователя [14]. Корневая причина — слепая SQL-инъекция в content providers (PushMessageProvider, PushShopProvider). Это означает, что даже при отсутствии SS7-доступа вредоносное приложение на устройстве может перехватить OTP до того, как его увидит пользователь.

Ошибки бизнес-логики на уровне SMS-уведомлений

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

Отсутствие rate-limit на endpoint отправки SMS позволяет инициировать массовую рассылку на любой номер. Это не только DoS для пользователя (телефон заспамлен), но и прямые финансовые потери — SMS-шлюзы тарифицируются по количеству сообщений. OWASP Business Logic Security Cheat Sheet прямо указывает: глобального rate-limit на уровне edge недостаточно, каждый чувствительный endpoint нужен свой лимит [15].

Шестизначный цифровой код (типичный OTP) даёт около 20 бит энтропии. При отсутствии блокировки после N неудачных попыток атакующий может перебрать все 1 000 000 комбинаций автоматически. OWASP рекомендует блокировку аккаунта или CAPTCHA после нескольких неудачных попыток, с более коротким TTL для SMS-кодов именно из-за этого [3].

Другой паттерн — раскрытие факта существования аккаунта. Если endpoint /request-sms-otp возвращает "User not found" для несуществующего номера и "SMS sent" для существующего, атакующий получает систему перечисления аккаунтов. Правильный ответ одинаков в обоих случаях: "If this number is registered, you will receive a code" [15].

Эти ошибки не обнаруживает WAF и не покрывает стандартный SAST: инструмент видит код, но не понимает намерение. Разница между "User not found" и "SMS sent" — семантика бизнес-процесса, а не синтаксическая проблема. Слой контроля, который анализирует конкретное изменение в контексте потока, помогает заметить такой паттерн до того, как он уйдёт в production.

Часть III. Push-уведомления: токены устройств, приватность и MFA fatigue

Архитектура и модель угроз

Push-уведомления на мобильных устройствах работают через посредников: FCM (Firebase Cloud Messaging, Google) для Android и APNs (Apple Push Notification service) для iOS. Приложение регистрируется у провайдера и получает device token — уникальный идентификатор для доставки уведомлений. Этот токен хранится у разработчика приложения.

Исследование 2024 года (arXiv 2407.10589) описывает три структурных риска этой архитектуры [16]:

Раскрытие: содержимое уведомления и его метаданные могут быть доступны неавторизованным сторонам.
Связывание: device tokens могут быть сопоставлены с конкретными пользователями или поведением.
Идентификация: через цепочку запросов к разным провайдерам можно деанонимизировать пользователя.

Это не теоретические риски. В декабре 2023 года сенатор Рон Уайден опубликовал открытое письмо, подтверждающее, что правоохранительные органы США регулярно получают push-токены через юридические запросы к Google и Apple [16]. Журналисты нашли более 130 ордеров с 2019 года, включая запросы против приложений, позиционирующих себя как «end-to-end зашифрованные» — Wickr и TeleGuard.

FCM Legacy Keys и уязвимость публичного ключа

Исследователь Dharani обнаружил, что FCM Legacy Server Keys позволяют отправлять запросы через устаревший HTTP-протокол, обходя требования HTTP v1, где нужен OAuth 2.0 access token [17]. При наличии leaked legacy key атакующий мог рассылать push-уведомления на устройства пользователей, в том числе подписчиков topic-каналов, охватывая потенциально миллионы устройств.

Этот класс ошибок типичен для AI-генерируемого кода: разработчик (или LLM) копирует пример из устаревшей документации, использует legacy API key, кладёт его в конфиг или .env, который попадает в репозиторий. HighVibe как слой контроля до merge флагирует именно такие изменения: появление нового ключа в конфиге, использование deprecated API-endpoint, отсутствие rotation-политики.

APNs и переход на JWT-аутентификацию

Apple в 2025 году завершила принудительный переход с certificate-based аутентификации APNs на token-based (JWT) [18]. Устаревшие сертификаты перестали работать. Сам по себе переход — шаг в сторону большей безопасности: JWT истекает каждый час, rotation автоматизирован.

Типичные ошибки при миграции:

Invalid Provider Token — неправильные Key ID, Team ID или истёкший JWT;
Device Token Not for Topic — bundle ID приложения не совпадает с сертификатом;
хранение приватного ключа APNs в репозитории вместо secrets manager.

Последнее — классический случай secret leakage в коде. Приватный ключ APNs даёт возможность отправлять любые push-уведомления всем пользователям приложения.

MFA fatigue: логическая атака через push

MFA fatigue — не техническая уязвимость, а атака на бизнес-логику пользовательского поведения. Атакующий, получив логин и пароль (через credential stuffing или фишинг), инициирует вход снова и снова. Пользователь получает поток push-запросов на подтверждение. В какой-то момент, особенно ночью или при усталости, нажимает «Подтвердить» чтобы остановить поток.

По данным Verizon DBIR 2025, количество MFA fatigue атак выросло на 217% год к году [19]. В 2025 году RedHat GitLab был скомпрометирован через локальный аккаунт без MFA — схема, аналогичная breachу Snowflake 2024 [20].

Технические контрмеры на уровне реализации push-MFA:

Number matching: в уведомлении отображается цифра, которую пользователь должен ввести в приложение (а не просто нажать «Подтвердить»);
дополнительный контекст: в push указывается геолокация, IP, тип операции;
rate-limit на количество запросов MFA в единицу времени;
алерт команде безопасности при аномальной частоте запросов с одного аккаунта.

Часть IV. Ошибки бизнес-логики: что объединяет все три канала

Перечисление аккаунтов

Самая распространённая ошибка — разные ответы для зарегистрированных и незарегистрированных адресов/номеров. OWASP Business Logic Security Cheat Sheet прямо указывает: "A password reset endpoint that returns different messages for valid and invalid emails leaks account existence" [15].

Правило простое: ответ должен быть одинаковым независимо от того, найден ли пользователь в базе. Это касается email, SMS и форм «забыл пароль». Нарушение этого правила не обнаруживается автоматическими сканерами — WAF не знает, какие ответы должны быть одинаковыми.

Отсутствие инвалидации токена

Токен, который не инвалидируется после использования, — это постоянный бэкдор. Если злоумышленник получил access к почтовому ящику даже спустя неделю, старый использованный токен не должен работать. OWASP строго требует однократности [3]:

Токен инвалидируется после первого использования.
Все ранее выданные токены для пользователя инвалидируются при выпуске нового (пользователь запросил сброс дважды).
При смене пароля все активные сессии завершаются.

Отсутствие привязки токена к действию и сессии

Частный случай: токен для подтверждения email используется для сброса пароля, или токен из одной сессии принимается в другой. Это нарушение принципа контекстуальной привязки токена. Каждый токен должен быть привязан к конкретному пользователю, конкретному действию и иметь флаг «использован».

Клиентская валидация вместо серверной

Пример из реального bug bounty (DevSecOps Guides 2025): endpoint /forgot-password принимает username и newPassword в теле запроса и меняет пароль без валидации токена [21]. Логика: фронтенд уже проверил токен и сделал запрос, зачем проверять повторно. Атакующий делает прямой POST-запрос к endpoint, минуя фронтенд. Пароль изменён без какого-либо токена.

Это классический anti-pattern: доверие клиентской стороне. Вся логика валидации — на сервере, всегда.

Характерная деталь: подобный PR выглядит как рабочий и проходит автоматические тесты — фронтенд-интеграция работает, happy path зелёный. Проблема видна только если смотреть на endpoint в изоляции от UI: принимает ли он запрос без токена? Это именно тот вопрос, который стоит задавать при ревью изменений в auth-flow до merge, а не в ходе пентеста спустя полгода после релиза. HighVibe как дополнительный слой контроля до merge анализирует именно такой контекст: новый или изменённый endpoint, связанный с аутентификацией или уведомлениями, разбирается в привязке к бизнес-процессу — есть ли там валидация токена, rate-limit, одинаковые ответы для существующего и несуществующего пользователя. Не вместо ревью, а как страховка от того, что в быстро растущем PR эти детали дочитают не до конца.

Race conditions в многошаговых потоках

Race condition в уведомлениях — это не только «два клика на одну ссылку». Это любой поток, где несколько шагов связаны состоянием, которое не защищено атомарно. Например:

Пользователь запрашивает SMS-OTP и одновременно изменяет номер телефона. Какой номер получит код?
Два параллельных запроса на сброс пароля для одного аккаунта. Какой токен действителен?
Подтверждение email происходит одновременно с удалением аккаунта.

Outpost24 фиксирует: race conditions плохо воспроизводятся при разовом тестировании и оставляют цепочки ложных негативов при неправильной защите [22]. CVE-2024-58248 — пример race condition в endpoint подарочных карт, позволивший использовать одну карту несколько раз через single-packet attack.

Часть V. Чек-лист: что проверять до merge и релиза

Email-уведомления

Токен генерируется через CSPRNG, минимум 128 бит энтропии.
Токен однократного использования: реализована атомарная UPDATE WHERE used_at IS NULL.
TTL токена: для login/reset — до 15 минут; для email verification — до 24 часов.
Страница, куда ведёт ссылка, устанавливает Referrer-Policy: no-referrer или strict-origin-when-cross-origin.
Токен не попадает в логи (настроен масking в конфигурации nginx/reverse proxy).
Отсутствует open redirect на странице с токеном.
Новый запрос инвалидирует все предыдущие токены для того же пользователя/действия.
При успешной смене пароля инвалидируются все активные сессии.
Ответ endpoint одинаков для существующего и несуществующего email.
Endpoint защищён rate-limit'ом (не только глобальным, но и per-email/per-IP).

SMS-уведомления

Rate-limit на отправку: per-number, per-IP и общий лимит в единицу времени.
Код — минимум 6 цифр; лучше использовать alphanumeric при возможности ручного ввода.
TTL кода: не более 5–10 минут.
Блокировка или CAPTCHA после N неудачных попыток (типично: 3–5).
Ответ endpoint одинаков для существующего и несуществующего номера.
SMS как единственный фактор недопустим для высокорисковых операций (финансы, смена email/пароля администратора).
Проверено: SMS не является fallback-каналом после включения более сильного MFA.

Push-уведомления

Device token хранится в защищённом хранилище, не в plaintext в БД.
Приватный ключ APNs/FCM — в secrets manager, не в репозитории.
Используется текущий протокол FCM HTTP v1 (OAuth 2.0), а не legacy HTTP.
Реализован number matching для push-MFA.
Rate-limit на количество MFA-запросов с одного аккаунта.
Push-уведомление содержит контекст операции: устройство, время, геолокация.
Алерт при аномальной частоте MFA-запросов.

Бизнес-логика (общее)

Все проверки токенов — на сервере, не на клиенте.
Каждый токен привязан к: пользователю, действию, TTL.
Параллельные запросы обрабатываются атомарно (транзакции, pessimistic/optimistic locking).
Логика не раскрывает факт существования аккаунта через разные ответы.
Чувствительные endpoint'ы имеют индивидуальные rate-limit'ы, не только глобальный.
Логи не содержат токены, OTP-коды, session secrets.

Часть VI. Кейсы и паттерны из bug bounty и инцидентов

USPS API (2018)

60 миллионов записей пользователей раскрыты через API, не проверявший авторизацию на объектном уровне. Любой авторизованный пользователь мог получить данные любого другого. Классический BOLA/IDOR, задокументированный как эталонный пример бизнес-логики без enforcement [1].

Coursera: токен в Referer (2018, HackerOne #303322)

Ссылка для сброса пароля открывала страницу с внешними трекерами. Токен уходил в Referer-заголовке на Bing и другие домены. Компания оценила риск как низкий из-за single-use природы токена, но bug был признан [7].

RedHat GitLab: local account backdoor (2025)

Инстанс GitLab был взломан через локальный аккаунт без MFA, существовавший параллельно с SSO. Атакующий не атаковал push-MFA напрямую — он нашёл путь, где MFA вообще не применялось. Урок: недостаточно защитить основной flow; ghost login paths — аккаунты, входящие по паролю мимо SAML/OIDC — такой же attack surface [20].

CVE-2025-10184: Android SMS без разрешений

SQL-инъекция в системных провайдерах Android позволяла любому приложению читать SMS без явного разрешения пользователя. Практический impact: обход SMS-OTP на устройствах с уязвимой версией ОС [14].

Часть VII. Тренды и то, что изменится в ближайшие 1–2 года

Несколько направлений, за которыми стоит следить команде.

SMS продолжит терять статус допустимого канала для сильной аутентификации. Регуляторы в финансовом секторе двигаются в сторону FIDO2/passkeys. В России регулирование пока не синхронизировано с международным, но банки и крупные платформы уже тестируют биометрию и TOTP как замену SMS-OTP.

Push-MFA с number matching становится де-факто стандартом для enterprise. Microsoft, Google и Okta переводят клиентов на этот режим как ответ на MFA fatigue.

Email как канал аутентификации (magic links) получает чёткие рамки в NIST SP 800-63B-4: AAL1, только с вторым фактором для AAL2. Это меняет архитектурные решения для SaaS-продуктов, особенно в B2B.

AI-кодинг создаёт дополнительный риск в этом слое: LLM-ассистент воспроизводит паттерны из устаревшей документации (legacy FCM key, SMS-only OTP, токен без инвалидации), а ревьюер, читающий диф быстро, не всегда замечает отсутствие бизнес-логики там, где она должна быть. HighVibe как дополнительный слой контроля до merge анализирует именно такие изменения — новый endpoint доставки уведомлений, изменение логики токена, появление API-ключа в конфиге.

Заключение: что делать дальше

Уведомления по email, SMS и push — это не UX-компонент. Это security boundary. Токен в URL — секрет. SMS-код — временный пароль. Push с кнопкой «Подтвердить» — ворота в аккаунт.

Большинство уязвимостей в этом слое невидимы для WAF и покрываются автоматическими сканерами лишь частично. Они находятся в пересечении бизнес-логики и реализации: отсутствие инвалидации, race condition, неодинаковые ответы, клиентская валидация, legacy API. Их видно при анализе конкретного изменения в контексте всего потока.

Три практических шага прямо сейчас:

Пройдитесь по чек-листу из части V по каждому notification-потоку в вашем продукте.
Убедитесь, что в pipeline есть проверка чувствительных endpoint'ов на предмет rate-limit, enumeration и токен-логики — не только на уровне SAST, но и на уровне ревью изменения.
Если команда использует AI для написания кода аутентификации и уведомлений, добавьте дополнительный gate до merge: изменения в auth-flow, notification-endpoint и конфигах должны проходить через человека или специализированный инструмент анализа изменений.

Именно для последнего пункта существует HighVibe — слой контроля до merge и релиза, который разбирает конкретное изменение в контексте: появился новый endpoint отправки SMS без rate-limit, изменилась логика инвалидации токена, в конфиг добавился ключ FCM. Инструмент не заменяет SAST, пентест или ревью, но закрывает gap, который возникает, когда AI ускорил разработку, а проверка безопасности не успела вырасти с той же скоростью. Короткий сигнал перед merge — можно ли безопасно принять именно это изменение — лучше, чем длинный отчёт после инцидента.

Источники

[1] Imperva — "State of API Security in 2024" — https://www.imperva.com/resources/resource-library/reports/the-state-of-api-security-in-2024/

[2] HackerOne — "8th Annual Hacker-Powered Security Report 2024/2025" — https://www.hackerone.com/resources/reporting/the-hacker-powered-security-report

[3] OWASP — "Forgot Password Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

[4] OnlineHashCrack — "Password Reset Tokens: Secure Implementation Guide" — https://www.onlinehashcrack.com/guides/password-recovery/password-reset-tokens-secure-implementation-guide.php

[5] Dimova et al. — "You've Got (a Reset) Mail: A Security Analysis of Email-Based Password Reset" (DIMVA 2021) — https://seclab.nu/static/publications/dimva2021youvegotmail.pdf

[6] Medium / InfoSec Write-ups — "Token Leakage via Referrer — The Invisible Slip to Third Parties" — https://infosecwriteups.com/token-leakage-via-referrer-the-invisible-slip-to-third-parties-9c8d326dd52c

[7] HackerOne — Report #303322, Coursera: password reset token via Referer — https://hackerone.com/reports/303322

[8] xorlab — "Open Redirect Vulnerabilities: The Hidden Danger in Email Security" — https://www.xorlab.com/en/blog/open-redirect-vulnerabilities-the-hidden-danger-in-email-security

[9] Medium / Lovelesh Gangil — "Open Redirection Vulnerabilities: Complete Guide" — https://loveleshgangil.medium.com/open-redirection-vulnerabilities-complete-guide-to-improper-front-end-redirect-validation-2d40599d8442

[10] NIST SP 800-63B-4 — "Digital Identity Guidelines: Authentication and Lifecycle Management" (August 2025) — https://pages.nist.gov/800-63-4/sp800-63b.html

[11] Security Boulevard — "Are Magic Links Secure: A Technical Deep Dive Into Email Based Authentication" — https://securityboulevard.com/2026/05/are-magic-links-secure-a-technical-deep-dive-into-email-based-authentication/

[12] P1 Security — "SMS-Based Attacks in Mobile Networks: Security Risks, Fraud, and Telecom Defenses" — https://www.p1sec.com/blog/sms-based-attacks-the-hidden-threat-still-exploiting-mobile-networks

[13] Authsignal — "SMS-based authentication: Why it's no longer enough for security" — https://www.authsignal.com/blog/articles/why-sms-based-authentication-is-no-longer-enough-for-secure-account-protection

[14] GitHub Advisory Database — CVE-2025-10184 — https://github.com/advisories/GHSA-q9jj-p5hc-gfmj

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

[16] arXiv — "The Medium is the Message: How Secure Messaging Apps Leak Sensitive Data to Push Notification Services" (2024) — https://arxiv.org/pdf/2407.10589

[17] PortSwigger Daily Swig — "Google Firebase messaging vulnerability allowed attackers to send push notifications" — https://portswigger.net/daily-swig/google-firebase-messaging-vulnerability-allowed-attackers-to-send-push-notifications-to-app-users

[18] React Native Insights — "APNs Update 2025: Preparing for Apple's New Push Notification Certificates" — https://reactnativeinsights.com/apns-update-apple-new-push-notification-certificates/

[19] Security Boulevard — "9 Identity-Based Threats Redefining Cybersecurity in 2026" — https://securityboulevard.com/2026/04/9-identity-based-threats-redefining-cybersecurity-in-2026-beyond-credential-stuffing/

[20] Push Security — "Push features we built in 2025 to stop browser-based attacks" — https://pushsecurity.com/blog/taking-the-fight-to-attackers-top-features-of-2025

[21] DevSecOps Guides — "Top Business Logic Vulnerability in Web" — https://blog.devsecopsguides.com/p/top-business-logic-vulnerability

[22] Outpost24 — "Business logic attacks: The silent future of cyberattacks" — https://outpost24.com/blog/future-business-logic-attacks/