Сервис Click to Pray, который связан с Папской всемирной сетью молитвы, оставил открытыми данные 719 517 аккаунтов. История важна не только из-за масштаба: уязвимость была предельно простой, а значит такой же сценарий легко пропустить в любом массовом сервисе с личными данными.
Уязвимость работала по базовому сценарию IDOR
Как пишет The Register со ссылкой на исследовательницу BobDaHacker, проблема сводилась к классическому IDOR: API-эндпоинт GET /user/users/{id} возвращал профиль пользователя по числовому идентификатору без нормальной проверки прав доступа. Достаточно было подставить другой ID, чтобы получить чужую карточку.
Ситуацию усугубляло то, что идентификаторы шли последовательно, а защиты от массового перебора, по данным исследовательницы, не было. Практический сценарий атаки выглядел слишком просто: запрос, смена номера, следующий запрос. В итоге злоумышленник мог последовательно собрать почти всю базу.
Какие данные оказались доступны
В ответах API, по данным публикаций The Register и Dark Reading, фигурировали имя, фамилия, адрес электронной почты, страна, дата рождения, а также технические поля вроде статуса удаления учетной записи. Для утечки это не самый экзотический набор, но для фишинга он почти идеален: есть почта, есть контекст, есть понятная аудитория.
BobDaHacker утверждает, что впервые сообщила о проблеме 3 января 2026 года, отправив уведомления на девять адресов, связанных с проектом. На момент публикаций 24 июля 2026 года ответа она так и не получила, а сама уязвимость, по ее словам, продолжала работать. Сухой итог: шесть с лишним месяцев тишины вокруг дыры, которую обычно находят на базовой проверке авторизации.
Ошибки не ограничились чтением чужих профилей
На этом история не закончилась. По словам исследовательницы, эндпоинт регистрации POST /user/users/sign-up возвращал validation_hash, который совпадал с токеном из письма для подтверждения почты. Проще говоря, новый аккаунт можно было подтвердить сразу, не дожидаясь письма и не имея доступа к чужому ящику.
Это уже не просто утечка персональных данных, а поломка самой логики доверия в сервисе. Если система считает адрес подтвержденным без реальной проверки почты, дальше появляются подмена личности, мошеннические регистрации и любые сценарии, где подтвержденный email используется как признак подлинности.
Дополнительная деталь выглядит почти как плохая шутка про информационную безопасность: письмо верификации, по словам BobDaHacker, ее почтовый клиент пометил предупреждением о проблемах с доменной аутентификацией. Для владельца продукта это худшая комбинация: у пользователей уже можно собрать адреса, а настоящие письма сервиса и без того выглядят подозрительно.
Почему этот случай важен для рынка
Для русскоязычных команд здесь нет ничего «ватиканского» или экзотического. Это типовой провал контроля доступа, который особенно опасен в сервисах с высокой лояльностью аудитории: религиозные проекты, медицина, образование, банки, государственные и окологосударственные платформы. Чем сильнее пользователь доверяет бренду, тем дороже обходится такая ошибка.
Отсюда и практический вывод. Знание ID, UUID или любого другого ключа не должно давать доступ к объекту. Проверка прав нужна на сервере для каждого запроса. Отдельно стоит проверить регистрацию: токены подтверждения не должны возвращаться клиенту, а ограничение частоты запросов не должно оставаться опцией «на потом». Иначе даже средняя по сложности ошибка быстро превращается в промышленный инструмент для сбора базы.
Следующий логичный шаг для Click to Pray — закрыть уязвимости, наладить прием сообщений от исследователей и объяснить пользователям, были ли данные реально собраны кем-то кроме автора находки.