Безопасность автоотклика: что получает сервис

Самый частый вопрос перед подключением автоотклика звучит так: «То есть я должен отдать вам пароль от своего аккаунта на площадке?» Короткий ответ — нет, и не потому, что это политика вежливости, а потому что вход на площадку устроен иначе: он выполняется одноразовым кодом. Поля, куда можно было бы ввести пароль, в этом сценарии просто нет.

Но вопрос от этого не закрывается, а смещается: если не пароль, то что именно получает сервис, где оно лежит и как это отозвать. Разберём по шагам. Общее устройство автоотклика описано в hub-статье автоотклик на вакансии, здесь речь только про доступ и данные.

Почему автоотклику нужен доступ к аккаунту

До декабря 2025 года отклики можно было отправлять через публичный API площадки — по токену, без всякого браузера. Затем API закрыли, и вместе с ним перестали работать боты и расширения, построенные поверх него. Подробности — в разборе почему сервисы откликов ушли с API на браузер.

После этого остался один способ: настоящий браузер, который открывает те же страницы, что открываете вы, и нажимает те же кнопки. Сравнение подходов и того, почему возврата к API не будет, разобрано в материале Playwright против API.

Браузеру, чтобы откликаться от вашего имени, нужна авторизованная сессия площадки — ровно то же самое состояние, которое живёт в вашем браузере после входа. Не пароль. Именно поэтому вопрос «где хранится пароль» для современного автоотклика поставлен неверно: хранить нужно сессию, и весь разговор о безопасности — про неё.

Как проходит вход и что при этом вводится

Вы входите сами, в реальном браузере, шаг за шагом.

Вход по коду. Вы указываете логин — почту или телефон, привязанные к аккаунту. Дальше открывается страница ввода одноразового кода: код приходит вам, вы его вводите, вход завершён. Пароль на этом пути не запрашивается ни разу.

Вход через социальную сеть. Если аккаунт на площадке привязан к ВКонтакте, Mail.ru или Одноклассникам, открывается страница входа самого провайдера. Пароль вводится в его форму, в его же окне, и используется ровно один раз — чтобы эту форму заполнить. В базу он не пишется, в файлы не сохраняется, повторно не используется: при следующем запуске работает уже сохранённая сессия площадки. Если провайдер спросит код подтверждения, он обрабатывается так же — как разовый ввод.

Капча. Проверка «подтвердите, что вы не робот» на входе возможна — она приходит от площадки и решается в том же окне. Обещать её отсутствие нельзя, и это относится к любому инструменту, а не только к нашему.

Что хранится после входа

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

Хранится оно в двух местах: в записи базы данных, привязанной к вашему профилю, и в файле состояния браузера на диске сервера. К файлам применяется отдельный набор правил, и работает он при каждой записи:

• Приватные права. Каталог сессий создаётся с правами 0700, файлы — 0600: доступ только у процесса-владельца. Права выставляются явно, а при создании файл дополнительно закрыт маской прав по умолчанию.
• Атомарная запись. Состояние пишется во временный файл со случайным именем, сбрасывается на диск и только потом заменяет прежний. Оборванная запись не оставляет полусохранённой сессии.
• Отказ вместо доверия. Если на пути к файлу оказывается символическая ссылка, если это не обычный файл или он принадлежит постороннему владельцу — сессия не сохраняется. При любом сомнении система прерывает запись, а не пробует продолжить.
• Имена файлов не логируются. Имя файла сессии — само по себе идентификатор, поэтому в отладочный вывод оно не попадает — ни при записи, ни при обслуживающих операциях.

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

Что вы контролируете

Доступ односторонний: он держится на сохранённой сессии, а сессию можно оборвать.

Отвязка в личном кабинете. Удаление подключённого аккаунта удаляет и запись о сессии, и файл её состояния. После этого запускать отклики нечем — нужен новый вход.

Завершение сеансов на стороне площадки. Это работает независимо от нас: сессия, завершённая площадкой, перестаёт быть валидной, и следующий запуск упрётся в требование войти заново.

Что сервис делает от вашего имени, а что — нет. В сохранённой сессии автоматизация открывает вакансии, отправляет отклики и читает резюме — то, что нужно для подбора и генерации письма. К переписке с работодателями на площадке она не подключается: ответы приходят вам как обычно. Правки резюме, которые предлагает разбор, применяются только после вашего подтверждения — сервис не переписывает анкету сам.

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

Про десктоп-приложение — отдельно. В нём браузер запускается на вашем компьютере, и сессия площадки остаётся на нём же — на сервер она не уезжает. Сервер в этой схеме отвечает за подбор вакансий, генерацию писем, историю и квоты. Для веб-площадок доступны оба варианта; для LinkedIn и Avito Работа — только локальный, потому что эти площадки отсекают трафик из дата-центров. Подробнее — на странице десктоп-версии.

Чего нельзя обещать

Честный разговор о безопасности включает и то, что не гарантируется.

Никто не может обещать отсутствие капчи, проверок или ограничений со стороны площадки. Браузерная автоматизация ближе к обычному поведению пользователя, чем запросы к закрытому API, но это меньше поводов для проверки, а не гарантия, что её не будет. Любой сервис, который обещает «гарантированную защиту от блокировок», обещает то, чем не управляет.

Не гарантируется и результат. Жёсткий суточный лимит откликов площадки нигде не объявляли — распространённое утверждение об обратном площадка не подтверждает. У JobTurbo при этом есть собственный защитный предел: до 200 успешно отправленных откликов на подключённый аккаунт за скользящие 24 часа на подписке и до 25 — на бесплатном тарифе. Это ограничение сверху, а не цель: почему разумный темп важнее максимального объёма, разобрано в статье сколько откликов в день отправлять.

Как JobTurbo решает это

Вот что всё это значит на практике.

• Пароль от аккаунта не запрашивается. Вы входите по одноразовому коду в реальном браузере, а при входе через социальную сеть пароль вводится на странице провайдера и не сохраняется.
• Хранится только сессия. Куки и состояние страницы — в базе и в файле с приватными правами, атомарной записью и отказом при любой подозрительной ситуации на пути к файлу.
• Логи не содержат персональных данных в открытом виде. Почта, идентификаторы и имена файлов сессий маскируются или не пишутся вовсе.
• Доступ отзывается в один шаг. Отвязка аккаунта удаляет и запись, и файл состояния.
• Никаких обещаний о том, чем мы не управляем. Ни про отсутствие капчи, ни про неприкосновенность аккаунта, ни про число приглашений.

Как устроен сам процесс отклика — от подбора вакансий до отправки письма — описано на странице как работает JobTurbo.

Итог

Вопрос «где вы храните мой пароль» устарел вместе с публичным API: вход на площадку идёт одноразовым кодом, и пароля в этой схеме нет. Хранится браузерная сессия — то же состояние, что живёт в вашем браузере после входа.

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

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