Мы запускаем свою доску объявлений и хотим защитить номера телефонов пользователей от парсинга. Как это сделать? Чтобы боты и другие пользователи не могли выгрузить базу номеров и использовать её в своих целях?
Чтобы защитить номера телефонов на доске объявлений от парсинга, можно использовать сразу несколько подходов — лучше не полагаться на один, а комбинировать.
Технические способы
- Не хранить и не отдавать номер в открытом виде на фронтенде. Вместо кликабельного номера показывай кнопку «Показать номер» или «Написать в мессенджер». Номер подгружай отдельным AJAX‑запросом только после действия пользователя (и желательно после капчи/проверки). Тогда в исходном HTML страницы номера просто не будет, и простой парсер его не вытащит.
- Обфускация в HTML/CSS. Можно разбить номер на части, вынести их в разные элементы, использовать CSS для визуального склеивания (например, через `display: flex` или абсолютное позиционирование), а в коде сделать так, чтобы «склеивать» номер приходилось уже в браузере. Для продвинутых ботов это не преграда, но отсечёт простые скрипты.
- Отрисовка номера картинкой или SVG. Номер генерируется на сервере как изображение/вектор и отдаётся как файл. Парсеру придётся делать OCR, что сильно усложняет задачу. Минус — хуже доступность (скринридеры, поиск по странице) и SEO.
- Динамическая подмена через JS. Номер собирается из фрагментов или декодируется в браузере. Можно использовать кодирование (base64 и т. п.) и сборку через JavaScript. Опять же, это не остановит серьёзного бота, но усложнит жизнь массовому парсингу.
Архитектурные и поведенческие методы
- Система личных сообщений внутри платформы. Не публикуй номер вообще. Дай пользователям писать друг другу через внутренний чат. В чате можно показывать номер только после взаимного согласия (например, после обмена несколькими сообщениями) или вообще не показывать его вовсе — пусть общение идёт через площадку. Это самый надёжный способ: нет номера на странице — нет парсинга.
- Лимиты и блокировки по IP и поведению. Вводи ограничения на количество запросов с одного IP за единицу времени. Отслеживай паттерны парсеров: слишком частые запросы, отсутствие «человеческих» действий (движения мыши, задержки между кликами), нестандартные заголовки User‑Agent. При подозрительной активности — капча, временная блокировка, возврат заглушки вместо данных.
- Уникальные токены для каждого просмотра. Если номер всё же нужно показывать, отдавай его не напрямую, а через эндпоинт вида `/api/show-phone?token=xyz`. Токен генерируй на бэкенде при загрузке страницы и привязывай к сессии/пользователю. Токен должен быть одноразовым или иметь короткое время жизни. Тогда просто «скопировать URL» и прогнать в цикле не получится.
- Рандомизация идентификаторов. Не делай так, чтобы по URL можно было перебирать объявления подряд (например, `site.com/ad/1`, `site.com/ad/2`). Используй UUID или другие непредсказуемые ID.
Защита на уровне данных и интерфейса
- Маскирование номера. Пока пользователь не совершил целевое действие, показывай номер в усечённом виде: `+7 (999) XXX-XX-12`. Полную версию — только после клика и проверки.
- Капча и поведенческая аналитика. Используй сервисы, которые анализируют поведение (движения мыши, время на странице, отпечаток браузера) и показывают капчу только подозрительным клиентам. Это снижает нагрузку на обычных пользователей.
- Запрет выделения и копирования. Можно через CSS (`user-select: none`) и JS запретить выделение текста с номером. Это слабая защита (не мешает «просмотреть код страницы»), но в связке с другими методами работает как дополнительный барьер.
Организационные и юридические меры
- Чёткие правила в пользовательском соглашении. Пропиши запрет на автоматизированный сбор данных и использование их в коммерческих целях.
- Мониторинг утечек. Периодически проверяй, не появились ли номера с твоей площадки в открытых базах или на других досках. Это поможет вовремя заметить утечку и скорректировать защиту.
- Блокировка известных парсеров. Веди чёрный список IP и User‑Agent, которые уже были замечены в парсинге. Кстати этафункция уже встроена в DST Доску объявлений в базовой версии.
Пример простой схемы защиты
Допустим, пользователь открывает объявление:
1. В HTML нет номера — есть кнопка «Показать телефон».
2. При клике фронтенд отправляет запрос на бэкенд с CSRF‑токеном и данными сессии.
3. Бэкенд проверяет лимиты, поведенческие факторы и капчу (если нужно).
4. Если всё ок, бэкенд генерирует одноразовый токен для этого номера и возвращает его фронтенду.
5. Фронтенд делает второй запрос: `/api/get-phone?token=abc123`.
6. Бэкенд отдаёт номер, помечает токен как использованный и логирует действие.
Что выбрать
- Если можешь — полностью уйти от показа номера и сделать внутренний чат. Это «золотой стандарт» для досок объявлений (как Авито и др.).
- Если номер обязательно должен быть на странице — комбинируй маскирование + подгрузку по действию + лимиты + токены.
Да и стоит не забывать что многие компоненты уже встроены в DST Board главное правильно настроить в панели управления. Но если нужна прям комплексна защита то это точно дополнительная работа т.к. тут нужна кастомизация.
Спасибо за ответ Артем, а можно еще спросить, я не сильно разбираюсь в разработке, могу я просто заказать работу чтоб это сделали т.к. как вижу тут много чего нужно делать?
Спасибо за ответ Артем, а можно еще спросить, я не сильно разбираюсь в разработке, могу я просто заказать работу чтоб это сделали т.к. как вижу тут много чего нужно делать?
На самом деле немного, для разработчиков это стандартные задачи. Выйдет примерно от 4 до 10 часов работы, смотря какой уровень защиты прописывать. В своем личном кабинете поставьте задачу и ее выполнят
Спасибо, Вы еще говорили что есть в базе некоторые функции защиты
Да все верно, но лучше и тут указать в задаче чтоб Вам настроили т.к. нужно понимать как настраивать и разработчики Вам настроят. Почему в базе нет всей защиты тоже объясню, методы парсинга регулярно меняются по этому это уже только кастомизация
