Как устроена безопасность публичного дейтинга

Базовая модель

Один запрос может быть нормальным, злоупотребляющим или опасным. Контекст решает все

В безопасности недостаточно сказать: "Я получил профиль через API". Нужно установить, кому профиль предназначался, была ли авторизация, какие поля вернулись, обошел ли запрос серверное правило и в каком масштабе он повторялся.

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

Граница данных

Публичная анкета не равна публичному аккаунту целиком

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

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

Называть весь ответ API "персональными данными в открытом доступе" без разбора полей - все равно что называть витрину магазина взломанным складом. Витрина действительно видна. Но это ничего не доказывает о доступе к подсобным помещениям.

Лайки и открытый дейтинг

Возможность лайкнуть известный публичный профиль - это нормальная продуктовая механика

Дейтинг существует для того, чтобы люди находили друг друга и выражали интерес. Если участник уже увидел публичную анкету в ленте, топе, поиске или по внутренней ссылке, возможность поставить реакцию логична. Неважно, отправил запрос официальный интерфейс или другой технический клиент: полномочие определяет сервер.

Фраза "через API можно лайкнуть любого" требует трех уточнений. Во-первых, речь идет о существующем публичном профиле, а не о доступе к чужому аккаунту. Во-вторых, запрос делает авторизованный пользователь от собственного имени. В-третьих, он остается внутри серверных лимитов и правил.

В текущем Mimolet лайки ограничиваются сервером по тарифу: 60, 250, 500 или 1200 действий в день. Поэтому возможность обратиться к маршруту реакции не равна безграничной возможности массово действовать.

Публичные фотографии

Если фото показано на экране, его можно сохранить. Ни одна соцсеть не способна отменить этот факт

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

Presigned URL полезен, когда нужно ограничить время доступа к исходному объекту. Он затрудняет повторное использование старой ссылки, но не стирает уже полученный файл. Запрет правой кнопки скрывает меню, но не защищает данные. Водяной знак помогает расследованию, но не запрещает копирование. DRM усложняет массовое извлечение видео, но тоже не блокирует запись экрана.

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

Скрейпинг без магического мышления

Автоматизацию нельзя уничтожить. Ее можно сделать дорогой, ограниченной и заметной

Скрипт способен повторять действия пользователя. Чем публичнее сервис, тем больше поверхностей для автоматизации. Поисковики сканируют страницы, аналитические системы собирают цены, маркетинговые инструменты анализируют соцсети, а злоумышленники имитируют браузер. Универсального переключателя "запретить скрейпинг" не существует.

Rate limit снижает скорость, но распределенный сбор использует множество адресов и аккаунтов. CAPTCHA отсеивает простые скрипты, но ухудшает доступность и решается внешними сервисами. Привязка к устройству помогает, но создает проблемы при смене телефона. Поэтому защита строится слоями и соразмерно реальному риску.

Из утверждения "автоматизация возможна" не следует "получена закрытая база". Между ними находятся тип данных, полномочия, скорость, полнота выборки и способность обойти защитные бюджеты. Публикация на Хабре перескакивает через эти ступени и сразу выбирает самое тревожное название.

Терминология

IDOR начинается не с числового ID, а с нарушения объектного разрешения

IDOR - это ситуация, когда изменение идентификатора позволяет получить объект, к которому у пользователя нет права доступа. Важна не форма ID и не возможность изменить URL, а именно отсутствие проверки полномочия.

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

Подписка и продуктовая логика

Лайкнуть известную анкету и раскрыть список тех, кто лайкнул вас, - не одна и та же функция

Premium в дейтинге часто дает доступ к входящим лайкам, расширенным фильтрам, приоритету и дополнительным лимитам. Это не означает, что подписка продает право поставить лайк конкретному человеку. Если профиль уже найден в публичной части продукта, обычная реакция остается обычной реакцией.

Чтобы доказать обход Premium, нужно показать, что бесплатный пользователь получил именно платный результат: реальную личность во входящем лайке, исходную фотографию, массовую обработку или другую закрытую возможность. Наличие общего маршрута реакции этого не доказывает.

В текущем Mimolet бесплатный ответ вкладки входящих лайков не раскрывает настоящий ID, имя или исходную ссылку на фото. Массовый ответ проверяет подписку на сервере. Поэтому тезис должен оцениваться по текущему результату, а не по внешнему сходству двух кнопок.

Сессии, устройства и блокировки

Несколько активных сессий - нормальная функция. Session fixation - конкретная атака

Пользователь может войти с телефона, браузера и Telegram Web. Каждое устройство получает свою сессию. Сам факт одновременной работы нескольких токенов не говорит, что злоумышленник навязал жертве заранее известный идентификатор. Без этого механизма термин session fixation применен неверно.

Жесткая привязка к IP тоже не является универсальной "базовой защитой". Мобильный адрес меняется между вышками, CGNAT объединяет тысячи людей, VPN переключает выходные узлы. Такая проверка создает массовые ложные выходы и почти не помогает против атакующего в той же сети.

Содержательная проверка другая: может ли заблокированный аккаунт продолжать защищенные действия. Текущий API Mimolet проверяет статус блокировки на каждом авторизованном запросе. То есть решение принимает сервер, а не экран, на который перенаправили пользователя.

Исторический код и текущий продукт

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

Первая публикация строит значительную часть выводов на нескольких PHP-файлах и отрицательном offset. Сегодня эти точки входа не обслуживают продукт. Текущий Mimolet работает через другой API с обязательной авторизацией и серверными проверками.

Текущие 404 не переписывают историю и не доказывают состояние конкретного дня в прошлом. Они доказывают другое: использовать старые маршруты как описание нынешнего продукта нельзя. Для актуального вывода нужно повторять тест на актуальной архитектуре.

От сетевого запроса к фантазии о бизнесе

API не показывает договоры, бухгалтерию, рекламодателей или банковские счета

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

Тем не менее публикация соединяет эти разные числа в историю о продаже рекламы, "левых счетах", инвесторах и намеренно ослабленной безопасности. Ни один из этих выводов не подтвержден доступом к договорам, банковским данным, бухгалтерии или аналитике компании.

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

Баллы, эмодзи и авторитетный вид

CVSS измеряет конкретную уязвимость по вектору. Это не шкала эмоциональности текста

Оценка CVSS складывается из формальных параметров: доступность по сети, сложность, требуемые привилегии, участие пользователя, влияние на конфиденциальность, целостность и доступность. Чтобы число можно было проверить, публикуют полный вектор и точные условия эксплуатации.

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

Правовая квалификация тоже требует фактов о составе данных, режиме обработки, действиях оператора и применимом праве. Подпись "нарушение ФЗ-152" под таблицей не превращает частное мнение в решение регулятора или суда.

Проверяемый пример из второго поста

Баннер Exim показал базовую версию, но автор выдал ее за полную ревизию Ubuntu

Второй пост использовал строку Exim 4.97 Ubuntu как доказательство CVE-2026-45185. В дистрибутивах Linux это недостаточно: исправления часто бэкпортируются без смены базовой версии программы. Внешний баннер не показывает суффикс пакета Ubuntu.

Официальная карточка Ubuntu указывает, что для Ubuntu 24.04 исправление вошло в 4.97-4ubuntu4.5. На сервере эта ревизия была установлена 14 мая, следующая .6 - 3 июня. Пост опубликован 27 июня. Значит, проверяемый вывод об "уязвимой версии" был неверен уже на дату публикации.

Качество исследования

Большой дамп не заменяет минимальное доказательство, а AI-стиль не заменяет проверку

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

Текст публикации содержит заметные признаки генерации или тяжелой AI-редактуры: повторяющиеся матрицы severity и business impact, однотипные аналогии, эмодзи-оценки, шаблонные резюме и уверенные выводы при пропущенных источниках. Это не доказывает конкретную модель, но помогает понять, почему форма выглядит убедительнее содержания.

Что имеет значение сегодня

Реальная безопасность Mimolet оценивается по текущим границам, а не по архивной драматургии

Ни один живой сервис не заканчивает работу над защитой. Лимиты уточняются, антибот-сигналы усиливаются, старые маршруты удаляются, права доступа получают регрессионные тесты. Но бесконечное стремление к недостижимой абсолютной защите не должно подменять бизнес-реальность открытого продукта.

• Текущие профиль и лента требуют авторизацию и без входа возвращают 401.
• Упомянутые legacy-маршруты и диагностический файл удалены и возвращают 404.
• Статус заблокированного пользователя проверяется на каждом API-запросе.
• Лайки ограничиваются сервером, а не только интерфейсом.
• Бесплатные входящие лайки не раскрывают реальный ID, имя и исходный путь фото.
• Публичный листинг S3 закрыт, а новые имена медиа не строятся на Telegram ID.
• Опубликованное публичное фото остается сохраняемым, потому что иначе его невозможно показать.

Точная формула проста: публичность контента - продуктовая модель, API - транспорт, скрейпинг - риск масштаба, а уязвимость - доказанный обход конкретной границы. Смешивать эти понятия удобно для сенсации, но бесполезно для безопасности.