Какие способы авторизации на сайте могут создать риски для бизнеса в 2026 году

Вход через Google, Apple ID и другие зарубежные сервисы долго считался обычной частью удобного интерфейса. Пользователь нажимал одну кнопку и попадал в личный кабинет без отдельного пароля. В 2026 году владельцам российских сайтов стоит воспринимать такие механизмы уже не только как вопрос удобства, но и как объект обязательной юридической проверки сайта.

Ограничения на способы авторизации появились раньше, а с 7 июля 2026 года за нарушение требований действует отдельная административная ответственность. Для юридических лиц штраф за первое нарушение может составить от 500 до 700 тыс. рублей. При повторном нарушении сумма возрастает до 1–1,4 млн рублей.

Поэтому проверять нужно не только видимые кнопки на сайте. Риск может скрываться в старом модуле CMS, приложении, API или внешней системе идентификации.

Какие способы входа предусмотрены законом

Для пользователей из России законодательство устанавливает ограниченный набор вариантов идентификации.

К ним относятся авторизация:

• по номеру мобильного телефона;
• через ЕСИА;
• с применением Единой биометрической системы;
• через информационную систему, владелец которой соответствует установленным российским требованиям.

Практический вывод для бизнеса простой: нельзя исходить из того, что любой привычный OAuth-сервис автоматически подходит для российского сайта. Особенно внимательно стоит проверить вход через иностранные платформы.

Почему проблема не ограничивается кнопкой «Войти через Google»

На многих сайтах социальная авторизация подключалась несколько лет назад. Со временем дизайн менялся, некоторые кнопки скрывались, а технический модуль оставался активным.

Например, пользователь может не видеть Google на основной форме входа, но такой вариант продолжает работать:

• на старой странице личного кабинета;
• в мобильной версии;
• через отдельный адрес авторизации;
• внутри приложения;
• через API;
• на тестовом поддомене.

Поэтому визуального просмотра сайта недостаточно. Нужно выяснить, какие системы реально участвуют в создании и подтверждении пользовательской сессии.

Шаг 1. Соберите все точки входа пользователей

Начать аудит стоит с карты пользовательских сценариев.

Проверьте, где посетитель может зарегистрироваться или войти:

• личный кабинет;
• форма регистрации;
• корзина и оформление заказа;
• подписка;
• комментарии;
• партнерский раздел;
• закрытая часть сайта;
• мобильное приложение.

Для каждой точки нужно зафиксировать доступные варианты идентификации. Если встречаются кнопки «Войти через Google», «Продолжить с Apple» или другие внешние сервисы, их следует передать на отдельную проверку.

Шаг 2. Посмотрите, что установлено в CMS

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

Разработчику стоит проверить:

• модули OAuth;
• плагины социальной авторизации;
• сторонние библиотеки;
• обработчики входа;
• внешние API;
• старые компоненты;
• настройки личного кабинета;
• резервные версии проекта.

Для WordPress, Drupal, Bitrix, OpenCart и других CMS такая проверка особенно актуальна, потому что функциональность нередко подключалась готовым решением.

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

Шаг 3. Отдельно проверьте мобильное приложение

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

Поэтому разработчику нужно отдельно проверить:

• экран регистрации;
• экран авторизации;
• API входа;
• SDK сторонних сервисов;
• восстановление учетной записи;
• связь аккаунта приложения с аккаунтом на сайте.

Это важно и с точки зрения удобства. После замены способа входа существующие пользователи не должны потерять доступ к своим данным.

Шаг 4. Не путайте регистрацию с авторизацией

Эти процессы связаны, но технически различаются. Регистрация создает новую учетную запись. Авторизация подтверждает право пользователя войти в уже существующий аккаунт.

Например, человек мог первоначально зарегистрироваться по электронной почте, а затем использовать Google для повторного входа. Поэтому при аудите недостаточно посмотреть только способ создания аккаунта.

Нужно разобрать весь сценарий дальнейшей идентификации.

Что делать с Google и Apple ID

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

Задача должна решаться совместно.

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

После этого уже выбирается вариант замены. Просто переименовать кнопку или скрыть ее стилями недостаточно.

Пример из практики

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

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

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

В таких задачах главный риск часто находится не на видимой странице, а внутри старой архитектуры проекта.

Что должно войти в техническое задание разработчику

Проверку лучше оформлять как отдельную задачу, а не как просьбу «убрать Google».

В ТЗ можно включить следующие пункты:

• найти все формы входа и регистрации;
• определить все используемые сервисы авторизации;
• проверить CMS, плагины и OAuth-модули;
• проверить мобильное приложение;
• найти прямые URL обработчиков входа;
• проверить тестовые сайты и поддомены;
• описать передачу данных внешним системам;
• предложить альтернативный способ авторизации;
• сохранить доступ существующих пользователей;
• провести итоговое тестирование после изменений.

Так разработчик понимает, что нужно проверить весь механизм, а не только внешний интерфейс.

Какие данные передать юристу

Юристу полезно получить техническое описание без лишней терминологии.

В него стоит включить:

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

Отдельно стоит проверить политику обработки персональных данных и пользовательское соглашение. Изменение способа авторизации может потребовать корректировки и этих документов.

Какой штраф может получить бизнес

Для юридических лиц за первое нарушение предусмотрен штраф от 500 до 700 тыс. рублей.

Если нарушение повторяется, диапазон становится значительно выше – от 1 до 1,4 млн рублей.

Поэтому формулировка «штраф до 1,4 млн рублей» требует пояснения. Такая верхняя граница относится именно к повторному нарушению.

Для должностных лиц и граждан предусмотрены отдельные размеры ответственности.

Когда стоит проводить проверку

Откладывать аудит до очередного редизайна или обновления сайта не стоит.

Особенно актуальна проверка для проектов, где есть:

• личный кабинет;
• интернет-магазин;
• подписка;
• программа лояльности;
• мобильное приложение;
• пользовательский контент;
• партнерский кабинет;
• закрытый раздел для клиентов.

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

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

Материал проверен редакцией «Поисковая индустрия»

FAQ: популярные вопросы и ответы